Seamless attach: live session status, a question inbox, and passive notifications — the UX layer over the fleet's existing foundations #1785

The feature

From any fresh VS Code window on any machine: open the panel, see every hub session with its live status, click one, watch it stream, answer its question without opening it — and get told when a session you follow needs you. Seamless attach to hub sessions.

The hard part is already built — this week assembled the entire machinery by accident. The remaining work is a UX layer over three existing foundations.

The three layers that exist (evidence)

1. Transport — the hub-client posture (feat(extension): the hub-host client posture — amicode.hubServerUrl spawns nothing, the panel becomes one server (#1760 P4) #1784, merged, deployed, verified live). The extension spawns nothing and every server resolution is the hub (amicode.hubServerUrl armed on erlich; the global-sdk-event-url assert in client-errors.log proves the stream URL). One door, one origin: opening a hub session is opening the hub.
2. State — P2's shared runtime rows (feat(core): P2 shared runtime state — busy/questions/permissions/registration as TTL'd store rows, replies idempotent (#1760) #1762, live). Busy, pending questions, permissions, and registration are TTL'd rows in the shared store, readable from any engine, any client. Any panel can already see what every session is doing — the data is sitting there.
3. Events — the merged streams with cursor replay (dd2788a + Fleet thin client — Slice 4: lossless SSE reconnect (cursor resume) #1264 + the dead-man's switches, live). Any client that opens a session gets its full live event flow; reconnects replay the gap. Verified end-to-end by the headless probe suite.

The three slices (all render/UX composition; none touch the engines)

• S1 — status chips on the session list. Wire P2's busy/question rows into the list rows: running · step 12, waiting on question, idle 40m. Render-only over existing state.
• S2 — the question inbox. The dock only surfaces inside an open session view, so a question asked while you're elsewhere goes unnoticed — sessions have hung on answerable questions for hours this week because of exactly that. The shared question rows already exist fleet-wide (a stale one surfaced cross-shard in a user's panel the day P2 landed — correct data, no inbox to receive it). One inbox surface (badge + side panel listing every pending question with its session), riding the reply path that now works end-to-end.
• S3 — notifications through the extension's event stream. The extension host already holds an SSE connection to the hub (sseClient); watch question.asked and turn-idle events on followed sessions and raise VS Code-native notifications. This is what makes attach passive — the panel taps you, you don't watch the panel.

Acceptance

Headless probe suite end-to-end: a fresh client boots, the session list shows live status for a running session, a question asked by a session the client has NOT opened surfaces in the inbox and is answerable from there (200, turn resumes), and the extension host raises a notification on question.asked. No session can silently wait on a human again.

Notes

• The reply instrumentation in the live dist (question-reply-attempt/ok/failed captures) is diagnostic and should be reverted once S2 lands with its own telemetry — or kept as the floor if the session prefers.
• Composes entirely with what's live; no engine deploys required unless a slice discovers a state gap — name it if so.
• The fleet session-status work on main (fix(fleet): remote session keeps its working rail + tab state after reopen (fleet-aware status re-seed) (#1766) #1768, the free-tier-fleet lineage) is the same shape for the peer-fleet model — read it before building; where the designs rhyme, rhyming them keeps the two lineages convergent (see the peer-fleet × hub-fleet reconciliation lane).