Step 1: Voice persistence + receiving-session indicator

[heavygee]

Goal

Make a voice conversation survive page navigation and tab refocus within the HAPI web UI, with an unmissable indicator of which session is currently receiving voice.

Spec

• docs/plans/2026-06-03-overseer-build-sequence.md Step 1 (primary)
• docs/plans/2026-06-03-overseer-framing.md "Persistence across devices is load-bearing infrastructure", "The chrome-button insight"

Acceptance

• Voice conversation survives page navigation within the HAPI web UI.
• Voice conversation survives tab refocus.
• Visible indicator on the receiving session card AND a persistent pill in chrome ("voice → session X").
• Navigating to a different session while voice is active in session A keeps the indicator showing "voice → A"; operator can type into session B at the same time (multi-modal multi-task by design).
• If the underlying receiving session goes down mid-convo, the voice layer surfaces it ("session A just dropped — end voice or spawn a fresh session?") rather than dying silently.
• Indicator data model accommodates future states: voiceFocus: { kind: 'session' | 'overseer' | 'fleet', ref?: string } so the later chrome-button move does not require a rewrite.

Out of scope

• Cross-device / mid-session live handoff (post-MVP). Cold-attach only.
• Chrome-level relocation of the voice button out of per-session UI — that is Step 5 (Step 5: Chrome-button move + per-session button retirement #27).
• Routing voice to the Overseer entity — that is Step 3 (Step 3: Read-only Overseer wired to voice #25).

Dependencies

• Blocks: none (independent quality-of-life win)
• Blocked by: none — intentionally parallel to Step 2: Events table + worker emission #22-Step 2.75: Replay harness v0 + CI gate #24; ship anytime
• Part of: Fleet Overseer architecture — umbrella #19

Suggested PR breakdown

1 PR: voice persistence + receiving-session indicator.

Risks

• Cross-device persistence is genuinely hard (server-side voice session state, multi-client attach, transcript replay, graceful failure when worker sessions die mid-convo). Step 1 only requires within-tab persistence; cold-attach is the MVP target and mid-session live handoff is explicitly post-MVP.

[heavygee]

Clarification on what this persists (voice-layer sequencing).

This step persists the existing heavy realtime conversational per-session voice — it is not a stripped-down dictation mode. Keeping the conversational agent and letting it float across sessions is deliberate: it is the best available demonstration of "you can hold a conversation while doing other work" (the core Overseer habit), and the persistence plumbing (server-side voice-session state, multi-client attach, transcript replay) is exactly what the chrome/Overseer voice surface will reuse.

The conversational mode is not removed here. It is replaced by lightweight dictation + read-back only at the atomic chrome-voice switch (#27), once the Overseer (#25) provides a home for conversation. The voiceFocus: { kind: 'session' | 'overseer' | 'fleet' } model means that switch is a re-target (session → overseer), not a rewrite.