Agent rail resilient to mount churn (StrictMode / remount) + reconnect-refetch

Root cause: the socket lived inside the component

useAtlasRail owned its WebSocket inside AddMatterWizard. The hook's unmount cleanup closed the socket and the next launch reopened a new one. So any churn of the component holding the hook tore the live run down:

• Dev — StrictMode double-invokes mount → cleanup → mount, running the close-socket cleanup on every run.
• Prod — a transient remount of the wizard / Step-5 panel during wizard data-load did the same for ~15% of runs (14/96 over 24h, per the broker trace).

The fix: lift the connection out of the React tree

• New src/lib/agents/atlas-rail-store.ts — a module-scoped registry Map<formId, AtlasRailConnection>. Each connection owns the socket, the RailState, the watchdog, and the launch/query lifecycle (all the transport that used to live in the hook). The pure reduceFrame in atlas-rail.ts is unchanged — same transport/decision split as before.
• Subscriber refcount + grace window — the hook subscribes/unsubscribes; a connection with zero subscribers is disposed only after a 3s grace. A synchronous StrictMode unmount → remount (and any brief real remount) re-subscribes within the window, so the socket and the live run survive the gap. A genuinely-closed wizard gets no new subscriber and is then torn down.
• use-atlas-rail.ts is now a thin subscriber — useSyncExternalStore over the connection; it owns no socket. Public API is unchanged (turn / thread / status / retryable / isStreaming / streamingMessageMd / send / retry), so Step5ReviewForm and the wizard are untouched at the call site.

AC#2 — stop the prod remount from orphaning the run

The connection is keyed by formId. For a remount to reuse the live run, that key must be stable across the remount — but formId was useState(crypto.randomUUID()) inside the wizard, so a wizard remount minted a fresh id and a fresh run, orphaning the old one.

• formId ownership moved UP to LiveMattersListPage (the stable list page), regenerated once per wizard-open (openWizard) and threaded through AddMatterModal → AddMatterWizard (new optional formId prop; a local fallback keeps Storybook standalone).
• Result: a transient remount of the wizard / Step-5 panel now resolves to the same module-scoped connection (same live run, same socket) instead of churning it. StrictMode preserves the id already; this closes the prod-remount case too.

AC#3 — consume #356's query replay on a genuine drop

• On a mid-run socket onclose (status still running/launching), the connection reconnects and sends query for the in-flight runId (buildQueryMessage, new pure builder in atlas-rail.ts). The broker replays persisted truth — turn.completed+run.done (succeeded), filtered run.failed (failed), run.accepted (running) — which are exactly the frame types reduceFrame already settles on. No AgentCore egress on a refetch.
• No double-render — the broker can deliver the terminal turn twice (live-connection redelivery and query replay). The connection commits at most one turn.completed per run_id (completedRunIds), so the reply renders once. Recovery is also bounded (≤2 replay attempts per disconnect, reset on any healthy frame) so a down broker fails fast into a retryable error instead of looping.

Before → after

Acceptance criteria

• AC#1 — rail survives StrictMode/remount via a module-scoped connection keyed by formId; no socket churn per run. met
• AC#2 — the prod remount no longer mints a new run: formId lifted to the stable parent so a remount reuses the live connection. met
• AC#3 — a genuine mid-run close reconnects, sends query, feeds reduceFrame, settles, with per-run terminal dedup (no double-render). met
• AC#4 — live Step-5 run incl. a forced mid-run reconnect settles with the final frame. unit-modelled; live staging is the owner's final gate

Verification

• pnpm lint 0 errors (2 pre-existing add-matter warnings on untouched lines).
• pnpm test 542 passed — incl. the new atlas-rail-store.test.ts: launch+settle, no-relaunch on same signature, socket survives a brief unsubscribe→resubscribe, dispose only after the grace window, query replay settles once, and redelivery+query don't double-render.
• pnpm build compiled.
• git diff --check clean.
• The StrictMode churn is modelled deterministically by the unsubscribe→resubscribe test (the exact subscription pattern React StrictMode produces). Live staging verification — a real Step-5 run with a forced mid-run socket close — needs Production-Clerk auth + a live broker and is the owner's final gate; the broker half (#356) is already deployed.

Files changed

8 file(s), +746 / -209 lines