feat(chat): reconnect to running sessions from any tab/browser (T-52)

[jaesbit]

Why

T-52: closing a session's tab and reopening it doesn't reconnect to the running agent. The agent should keep running in the background regardless, and opening the same session from a second browser should live-sync both views over the shared WebSocket without killing either.

Root cause

Server-side was already correct: InProcessAgentBridge supports multiple concurrent WS subscribers per session (Active.subscribers: Set<string>), fans out session_events to all of them, and only reaps a session after it's been idle and has zero subscribers for idleTimeoutMs (never mid-turn). The gap was entirely client-side: the active session id (activeId) lived only in in-memory zustand state with no URL or localStorage backing, so any full page load (tab close/reopen, reload, a second browser) always started at activeId: undefined and landed on the empty picker — even while the agent kept running server-side.

Change

• New /c/:sessionId route + useSessionRoute() hook keeps the URL and the store's activeId in sync in both directions (URL to store on load/back-forward, store to URL on any other session change). Deep-linking to a session now works, and switching between two different sessions no longer gets clobbered by a stale localStorage default (caught this in manual verification — the store-to-URL mirror effect needed to wait for the URL-to-store adopt effect to run at least once, otherwise a localStorage-restored activeId could stomp a legitimate/different /c/:id link before it was ever adopted).
• A bare / restores the last-active session via a new localStorage-backed default, so a brand-new tab (not just a restored one) reconnects too.
• resumeIfKnown in the store: when a subscribe attempt comes back "session not active" (idle-reaped, or the server restarted) for a session that still exists on disk, transparently resumes it instead of leaving the tab stuck on a blank screen. Falls back to clearing activeId (back to the picker) only if the session genuinely doesn't exist.

No server or protocol changes — the multi-subscriber fan-out and idle-reap grace already existed; this closes the client-side reconnect gap only.

Verification

• bun run --filter '@omp-deck/web' typecheck — clean.
• cd apps/web && bun test — 139 pass.
• cd apps/server && bun test — 212 pass (unaffected, no server changes).
• bun run --filter '@omp-deck/web' build — clean production build.
• Manual browser verification against an isolated scratch server instance (separate port/db/workspace, not the live deck.service):
  • Fresh deep link to /c/:id loads the session directly (no picker, no 404).
  • Switching between two different /c/:id deep links adopts the new session correctly.
  • Bare / redirects to the last-active session via localStorage.
  • An unknown/bogus session id falls back cleanly to the picker at /.
  • Full page reload on a session URL stays on the same session with history intact.
  • Two tabs opened on the same session URL both hydrate the same live transcript; a message sent from one tab appears in the other without reloading.
  • Disposing the in-memory session handle (simulating idle-reap or a server restart) then reopening the same URL transparently auto-resumes the session from disk with full history, on the same URL.

Out of scope

Idle-reap timeout policy itself is unchanged (still disposes a session after it's genuinely idle with zero subscribers) — that's expected server-side resource hygiene, not the reported bug; the fix is that reconnecting to it is now transparent.