The chat showed a spinner for the whole run and only rendered when it finished,
even though the server's stream was correct — verified frame by frame against
production, one per second, each tool call and result as it happened:

  10:01:35  ⚙ $ echo STEP1
  10:01:35    → STEP1
  10:01:36  ⚙ $ echo STEP2

So the transport was fine and the client was not receiving it. Rather than chase
a long-lived stream through a proxy and a mobile network — where buffering, an
idle timeout or a handover all produce exactly this silence — the feed no longer
depends on the stream at all.

Two sources now race: SSE (instant) and a 1.5s poll of the running task
(guaranteed). Whichever is further ahead wins, compared by length because both
render the same append-only text. If the stream never delivers a byte the feed
still updates every 1.5s; if it works, it wins every time and the poll is
invisible. Polling targets GET /api/tasks/:id rather than the whole chat, so it
carries one run's output instead of every message's body on every tick.

Also: the stream now replays with from=0, so opening a chat that is already
mid-run shows what has happened so far instead of only what arrives next.

And "Working…" no longer appears twice — the bubble header says it, so the body
no longer repeats it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>