[BUG] /fast has no effect in desktop app — ON and OFF both ~11s; terminal ON ~2x faster (~6s)

Summary

Toggling fast mode (/fast) in the desktop app has no observable effect on output
speed — fast mode ON and OFF both take ~11s for an identical prompt. The same prompt
with fast mode ON in the terminal completes in ~6s. Fast mode appears to be a no-op
in the desktop client.

Steps to reproduce

1. Send this prompt and time wall-clock from submit to completion:

Write the numbers 1 to 300, one per line, nothing else.

1. Repeat across the surfaces / toggle states below.

Results (single trial each, human stopwatch)

| Surface | Fast mode | Time |
|----------------|-----------|-------|
| Desktop app | OFF | ~11s |
| Desktop app | ON | ~11s |
| Terminal (CLI) | ON | ~6s |

Expected

With fast mode ON, the desktop app should stream meaningfully faster than with it
OFF (same Opus model, accelerated output) — comparable to the terminal's ~6s.

Actual

Desktop ON and OFF are identical (~11s); the toggle does nothing. Terminal ON is
~2x faster (~6s), confirming fast mode works there but not in the desktop client.

Why this isn't just render overhead

Within the desktop surface, the only variable changed is the fast-mode toggle, and
it produced zero change (11s -> 11s). UI render cost affects both desktop runs equally
and cancels out, isolating the issue to fast mode having no effect in the desktop app.

Environment

• Claude Code: 2.1.158
• OS: macOS — Darwin 25.3.0
• Model: Opus 4.8

Not yet ruled out

• Single trial per cell (human stopwatch); runs not averaged.
• Terminal fast-OFF not captured (not needed — within-desktop ON==OFF is the proof).