Story-2223: Mira panel hydrates the persisted thread on mount

Mira's conversation turns already persisted server-side (functions #623 — agents.chat_turn with inline content). The panel kept the thread across minimise/reopen because the rail connection lives in a module-scoped registry. But a module is per-page-load: a full reload wiped it, so Mira reopened empty while both turns sat in the database. This story makes the panel read that durable thread back on mount.

The shape of the fix

The rail's thread was only ever written by live WebSocket frames. Nothing read the durable copy. So the change is one new inbound path — two generated reads feeding one new store method — and no change at all to how live turns arrive.

1. useAppListAgentSessions(matterUuid, { agentKey: "mira_matter_chat" }) finds the counsel's live Mira session for this matter. The list is newest-active first, so the head is the thread to replay.
2. useAppLoadAgentSessionTurns(sessionId) loads that session's turns, oldest-first. The generated hook's enabled gate means a matter with no session issues no turns request at all.
3. chatTurnsFromPersistedTurns() maps the wire onto the rail's vocabulary, and connection.hydrateThread(sessionId, turns) seeds the thread.

Files

Two boundary details the wire forces

• Roles are storage vocabulary. The database speaks user/assistant; the rail speaks counsel/atlas. Anything that is not user renders as the agent, so a future system/tool role degrades to agent prose rather than vanishing.
• content is null when the body overflowed to S3. contentPreview is always inline, so it is the honest fallback: a truncated turn beats a blank one.

Why the greeting disappears while loading

The panel's empty state says, in effect, "ask me anything". Showing that to a counsel whose conversation is one fetch away tells them their history is gone. So while isHydrating is true the thread renders nothing. This costs no new copy (and so no new i18n keys), and in practice is almost never seen: the dock's open state is ephemeral by design, so by the time a counsel reopens the panel after a reload, hydration has landed.

Never destroying live truth

hydrateThread carries two guards, both about the same worry:

• Once per session id. A refetch, a re-render, or a reconnect re-applies nothing. An empty session still marks hydration done, so a fresh matter does not refetch forever.
• Never over a non-empty thread, never mid-stream. If counsel typed before the fetch landed, their words win and the older server thread is dropped rather than prepended out of order.

Hydration also restores the history that the next launch sends the brain, so the first question after a reload is no longer asked in a vacuum.

Storybook coverage

Tests

• mira-rail.test.ts — role mapping, S3-overflow preview fallback, unknown role renders as agent.
• atlas-rail-store.test.ts — seeds an empty thread; idempotent per session; never overwrites live turns; an empty session is marked hydrated without touching the thread.

Verified live (system boundary, not fixtures)

Run against the staging gateway and staging data, signed in, on M-0013 — the matter from the issue's repro. Session 5029bd10-… holds exactly two inline turns.

• AC 1 — reload → open Mira → prior turns render. Confirmed. Full page load, open panel: status READY, both persisted turns rendered, no greeting. GET /api/internal/matters/ea90a732-…/agent-sessions?agentKey=mira_matter_chat → 200, then GET /api/internal/agent-sessions/5029bd10-…/turns → 200 with 2 turns.
• Empty first-run state. Confirmed on a matter with no Mira session: the sessions read returns {"sessions":[]}, no turns request is issued, and the greeting shows. (The doctrine's "fixtures lie in your favour" case, exercised for real.)
• Matter-switch isolation. Each matter resolves its own session id; the connection registry is already keyed on the matter UUID.

Unrelated defect noticed

The Brief page for M-0012 crashes the workspace with TypeError: Cannot read properties of undefined (reading 'value') at src/components/matter-detail/brief/frame-summary-history.tsx:387 (EditableFieldWithHistory), on a matter with a sparse frame. Out of scope here; surfaced for a separate Bug.