Replay-on-rehydrate: re-run the bound render selection on page reload

The split (why this is client-only, no functions change)

The render design is reference-only, so the fix is NOT to replay a stored data frame — it is to re-bind the persisted selection with fresh RLS at replay time. That re-bind happens server-side and is the paired functions ticket #1799 (now MERGED to functions main). Because #1799 re-binds the bound selection on replay, the client only needs to trigger the existing run-replay by run id — the broker returns RLS-fresh data for that selection. Re-emitting the selection from the app would duplicate the bound-selection source of truth, so the app does NOT. This app ticket is the page-reload side: kick the existing #356 query reconnect on mount. No new outbound message, no contract change, no functions change in this repo.

What changed

Where it lives

• src/lib/agents/dock-render-bridge.ts — NEW pure runIdFromRenderItemId (inverse of renderItemId); the run to replay is read off the render-${runId} id, which also keeps the redelivered live item's id matching the placeholder.
• src/lib/agents/atlas-rail-store.ts — NEW AgentRailConnection.resume(runId): adopts the run, shows loading, sends the existing buildDockChatQuery reconnect (a comment cites #1799 for why run id is sufficient); idempotent per run (resumedRunId).
• src/lib/agents/use-dock-chat-rail.ts — exposes rail.resume.
• src/components/agents/agent-dock-mount.tsx — rehydrate effect: re-run (replay) the persisted reference's run once on mount when no live render is present. Both ponytail: deferral notes replaced with the real re-run.
• *.test.* — bridge round-trip; rail-store resume asserts the rehydrate TRIGGERS the replay query AND that a redelivered render.data frame REPOPULATES state.render with RLS-fresh rows (+ idempotent); mounted-dock rehydrate e2e (persist → reload → resume fires; denied frame shows the VISIBLE denied state).

Verify

pnpm lint        # clean (1 pre-existing avatar.tsx warning, unrelated)
pnpm test        # 903 passed
pnpm build       # green
git diff --check # clean
# NOTE: do NOT run pnpm codegen — no contract change; import from src/gen.

• AC1 (re-run triggers + repopulates) the rail-store test drives the full path: resume(runId) shows loading and sends the type:"query" / agentKey:"atlas_dock_chat" / runId reconnect, THEN a redelivered render.data frame REPOPULATES state.render with RLS-fresh rows (render.rows[0].matterRef === "M-001") — proving the trigger produces a fresh component, not a stale placeholder. agent-dock-mount.render.test.tsx mounts the real dock: persist → cold reload → rail.resume("run_1") fires.
• AC2 (states) in-flight → loading (status); a redelivered state="denied" frame overrides the placeholder and renders the VISIBLE denied note ("This result is no longer available."), not the silent empty placeholder; unknown id → text fallback (the #1794 path, unchanged).
• AC3 (reference-only kept) the persist path is untouched; no row data reaches sessionStorage; the ponytail: notes are replaced with the real re-run.
• No wasted re-run a same-session live render skips replay (rail.resume not called); the replay is idempotent per run.
• No regression all tests green; the bridge round-trip + rail-store replay coverage is new.

Design (accepted): the re-run replays the run by id via the existing dock_chat query reconnect rather than re-emitting the selection. #1799 (merged to functions main) re-binds the persisted render selection with fresh RLS at replay time, so run id alone returns RLS-scoped data on rehydrate; re-emitting the selection would duplicate the bound-selection source of truth.

Non-goals (per the ticket): no functions changes (server re-bind is #1799), no row-data persistence, no new framework — the existing rail + loading/denied/empty/fallback states are reused.

Files changed

7 file(s), +299 / -11 lines