fix(site/src/pages/AgentsPage): stop gating chat stream parts on client status - #28207

…nt status

The chat stream handler dropped message_part events whenever the
client-side chat status read "waiting". The server only forwards
parts for the chat's current episode, so the gate was redundant with
the server-side episode filtering. Its only effect was to convert
client/server status skew into permanent output loss: dropped parts
are never re-sent, and once the status caught up to "running" with
no stream state, the UI showed a "Thinking" indicator that never
progressed until the page was reloaded.

The typical trigger was a reconnect replaying a stale waiting status
from a just-completed turn, followed by a fast re-send whose first
parts arrived before the new status event.

Apply parts whenever they arrive. Interrupt semantics are preserved:
status:waiting still discards parts buffered before it in the stream,
and the durable message commit still clears applied stream state.

🤖 Generated with Coder Agents

…ale waiting status

Adds a page-level story for the scenario fixed in the previous commit:
a chat record still reading "waiting" when a message_part arrives over
the stream. The play function asserts the thinking disclosure renders,
which fails against the pre-fix code and passes with it.

The play asserts on the disclosure header rather than body text because
the smoothing engine's requestAnimationFrame loop is suspended in the
test iframe, so smoothed body text never reveals there.

…d waiting

The ungated stream applied any arriving part, and a closed episode can
keep draining parts to the client for up to 15s server-side. With a
truly idle chat, those drain parts repopulated the stream and stayed
visible until the next turn or a reload.

Gate parts on a latch instead of on the status value alone: the latch
sets when the stream delivers an authoritative "waiting" status and
clears on any other stream status or error, and never moves on REST
hydration. So a part is dropped only when the server itself said the
turn ended, and still flows while a stale REST status lags a live turn.

…nstraint

FE4: drop the scenario restatement from the story doc; the fixture
itself is the code. Keep the one non-obvious constraint a future editor
needs: why the assertion targets the disclosure header rather than
streamed body text.

An optimistic setChatStatus("running") on send flips the store status
before the stream's authoritative status event arrives. With the gate
keyed on chatStatus, that reopened the window while the latch was still
set, letting drain parts from the just-closed episode append to the new
turn. Key the gate on the latch alone: an optimistic write carries no
signal about episode liveness, and only a stream status event clears it.