fix(chat): queue WS sends, replay buffer on initial bind

[alex-fedotyev]

Summary

Two small fixes for the user-visible chat glitch where a question gets no
response and the next reply ends up answering the previous prompt. Five
reliability PRs (#63, #64, #65, #66, #67) each close one underlying
cause; the two remaining gaps live at the client send path and the
gateway initial-bind handshake.

Gap 1: client send silently drops payloads

web/src/api/websocket.ts checked readyState === WebSocket.OPEN and
no-op'd otherwise. The 3-second reconnect window leaves a hole: a
disconnected send() returns nothing to the caller and
chatStore.sendMessage has already optimistically appended the user
message and flipped isStreaming: true. The UI shows "thinking" while
the message never reached the server, the next message succeeds, and
the user reads the second response as if it answered the first prompt.

The fix:

• send() returns 'sent' | 'queued' | 'dropped'. CONNECTING and
  "reconnect scheduled" go to a bounded _pending queue (5 entries,
  oldest evicted). onopen drains the queue in arrival order.
• chatStore.sendMessage captures the return value. On 'dropped'
  the optimistic user message is popped, isStreaming is cleared,
  and an inline assistant error explains the failure so the user can
  retry.

Gap 2: gateway initial bind never replayed the broadcaster buffer

nerve/gateway/server.py:286-311 registers the new listener but does
not ship session_status with buffered_events. The switch_session
handler at 363-379 already does. Reload mid-turn (or the 3s WS reconnect
after a network blip) and the in-flight stream is lost from the
client's view even though broadcaster._session_buffers[session_id]
has every event.

The fix:

• Lift the shared session_status construction into
  _send_session_status(websocket, session_id, is_running, session_record).
• Call it from the initial-bind branch only when
  broadcaster.is_buffering(active_session) is true. Idle sessions
  stay silent.
• switch_session calls it unconditionally so the client refreshes
  is_running / status on every selection.

The frontend handleSessionStatus already rebuilds streamingBlocks,
panels, todos, and interaction state from msg.buffered_events
(web/src/stores/handlers/sessionHandlers.ts:22-114, last updated by
#69), so this is purely additive at the gateway.

Test plan

• python -m pytest tests/test_gateway_ws.py -v (9 new tests
  covering the helper output, the initial-bind gate, the
  switch_session regression path, and a buffer-fidelity check).
• python -m pytest tests/ (444 pass, 2 skip, 2 pre-existing
  failures unrelated: test_bootstrap docker-env detection and
  test_cli_upgrade docker mode).
• npx tsc --noEmit clean in web/.
• npm run build clean in web/.
• Manual: open a chat, start a long-running turn, reload the tab
  mid-stream. The in-flight stream should restore (blocks rebuild via
  the buffer, todos via fix(web): refresh todos panel from buffered events on reconnect #69, isStreaming: true reflects live state).
• Manual: dev-tools "Offline" toggle for 5s during a turn. On
  reconnect, the buffer replays.
• Manual: force a send during the offline window. On reconnect,
  the message flushes ('queued' path) and the agent runs.
• Manual: force a permanent close (kill the daemon). Type and
  submit. UI shows the dropped-message error ('dropped' path) and
  the optimistic state is reverted.

Out of scope (followups, not blocking)

• Stale-listener cleanup on swallowed send_json exceptions
  (server.py:298-301).
• Application-level message_received ack broadcast from the engine
  after sessions.add_message.
• _session_locks TTL / reclaim on session archive.

Notes

[no-changeset: allow] (no changeset infrastructure in this repo).