fix(events): reconcile open session transcript after SSE reconnect

[omgoshjosh]

A prompt submitted from another client (CLI, TUI, a second device) while this client's SSE stream was down never appears in an already-open session until the user navigates away and back.

Root cause

resyncBusySessions() is the only reconnect-time reconciliation, and it returns immediately when no session is marked busy:

const busySessionIDs = Object.entries(useEvents.getState().sessionStatus)
  .filter(([, status]) => status.type === "busy")
  .map(([sessionID]) => sessionID)
if (busySessionIDs.length === 0) return

But a client only learns a session is busy from an SSE session.status event. If the stream was down when the other client submitted the prompt, this client never saw that event — so the session is still idle in its store, resyncBusySessions() finds nothing to do, and since reconnect resumes the stream from "now" without replaying missed events (as the comment above that function already notes), the messages from the gap are never fetched by anything.

The session screen does subscribe to reconnectAttempts, but only to render the reconnect banner. Nothing refetches on reconnect.

The change

reconcileOpenSession(), invoked alongside resyncBusySessions() in the same once-per-reconnect block: refetch the currently-open session's transcript unconditionally.

refreshMessages() replaces messages/parts without touching isLoading, so this lands as a silent background reconcile rather than a spinner over content the user is already reading — which only holds because #151 stopped same-session refreshes from forcing the loading state. The two changes are complementary:

• Closes #150 #151 fixed a spinner hiding content that was arriving.
• This fixes content that never arrives at all.

Same user-visible symptom, different layer.

It can overlap with resyncBusySessions() for a session that was busy and has since gone idle — both would refresh. That costs one redundant GET on an infrequent event, which seemed cheaper than the coupling needed to dedupe; happy to change that if you'd prefer.

Verification

Reproduced and verified on an Android 12 emulator against a live server:

Step	Result
Post a message while connected	Appears live — baseline SSE delivery works
Enable airplane mode	Banner shows "Reconnecting… (attempt 5)"
Post from another client while offline	Not shown on device — reproduces the bug's precondition
Restore network, wait, do not navigate	Message backfills automatically; banner clears; no spinner

The last step is the regression check: before this change the transcript stayed stale until the user left the session and re-entered. noReply: true was used throughout so the test exercises prompt acceptance, persistence and realtime delivery without model timing.

tsc --noEmit clean; full suite passes (286 tests) on this branch.

[omgoshjosh]

Folding this into #182 to keep the tracker tidy — same commit, same verification, just consolidated with the other two Android fixes rather than three separate PRs. Sorry for the noise.