Reconcile the running audio provider when SayPi authentication changes

[rosscado]

Problem

A host tab that stays open across SayPi sign-out or sign-in does not reconcile its running audio provider with the new authentication state, even though a fresh provider lookup can return the correct provider.

Scope and evidence

This concerns the running audio actor and host-audio ownership on Pi and the other supported chat hosts. It is separate from preserving the saved voice (#608), rendering the correct Pi sign-in notice (#607), the catalog invalidation fixed in #456, and the lost audio-element binding fixed in #602. The saved voice should remain a preference throughout an auth transition.

Source audit at d5b28cd394186a31774497224523b85f10155dee found:

• AuthStatusSync reconciles JWT state and emits saypi:auth:status-changed.
• SpeechSynthesisModule initializes the provider on construction, but its registered listeners do not subscribe to auth changes. Its provider getter now checks authentication after awaited preference reads; calling that getter does not update the actor.
• AudioModule updates the actor and host mute ownership on audio:changeProvider. No auth-change listener dispatches that update. The voice-menu auth listener refreshes its presentation only.

The missing subscription also existed before this release work; this is a separate follow-up, not a new regression attributed to #608. The audit establishes the missing handoff in source. An attended sign-out/sign-in playback reproduction has not yet been performed, so the exact audible effect across hosts and browsers still needs verification.

Reproduction / verification

1. Add a hermetic integration case using the real output actor, an authenticated context, and a saved remote voice. Initialize the provider through the normal event path.
2. Reconcile sign-out through the existing auth-status path without reloading the page or selecting another voice. Compare the actor provider and host-mute ownership with a fresh getActiveAudioProvider result. The current wiring leaves the actor on its previous provider.
3. Repeat from signed-out initialization through sign-in with the saved choice unchanged. Verify the next remote stream is accepted without requiring a second explicit voice selection.
4. During an attended host check, repeat the two transitions in an already-open Pi tab, then confirm the relevant behavior on Claude/ChatGPT. Record actual audible output, host mute state, and browser. Run a bounded confirmation turn only when authorized; no unattended account traffic is needed.

Expected: effective provider, actor acceptance, and host-audio ownership agree after auth reconciliation. Actual source path: JWT state and menu presentation can change while the running actor retains the old provider.

Acceptance criteria

• Both auth-transition directions update the effective running provider without a page reload or another voice selection.
• Signed-out Pi can use its native voice; signing in can resume an eligible saved remote voice. Hosts without a usable native fallback do not claim unavailable SayPi playback.
• A saved remote voice survives the transition, and a newer explicit voice choice wins over an older asynchronous reconciliation.
• Hermetic tests exercise the real actor and host-mute seam, including a transition during an outstanding preference read; getter-only assertions are insufficient.
• An attended confirmation records the supported-host behavior and any Chrome/Firefox differences without claiming unperformed checks.

Filed from independent Codex release review. Auth/JWT implementation, if required, remains subject to the repository's existing review and founder-sign-off rules.

[rosscado]

Taking this on in codex/pi-audio-ownership. The user has authorized fixing Pi native audio overlapping a custom voice selected in extension settings. The same missing reconciliation affects cross-tab preference changes, audio startup, and the auth transitions documented here. I will add fail-first tests against the real output actor and mute behavior, preserve saved choices, and protect newer selections from stale asynchronous reads. Direct audio-element insertion/replacement coverage will follow as a separate slice. No store release is part of this work.

[rosscado]

The running ownership reconciliation is merged in #619 (b23e815), with two independent approvals and all CI workflows green. Fail-first tests cover startup, cross-document preference changes, sign-out/sign-in effective ownership, stale async reads, unavailable voices, preview/replay continuity and shared-page playback. Native-player lifecycle hardening follows in #620 / #621.

The attended real-host confirmation requested here has not been performed in this session, and is not being claimed from the hermetic tests. Read-only Chrome evidence identified an unpacked 1.13.0 build and coexisting paused Pi audio elements; that observation does not establish a shipped-store incident. Keeping this issue open for the remaining attended confirmation. No real-host voice turns or store submissions were performed.

[rosscado]

Implementation follow-up is complete: #619 reconciles saved voice/auth changes, #621 now handles direct/nested/coexisting Pi players and shared replay lifetimes (merged86f2057), and #623 fixes the dictation focus race uncovered by Firefox CI. Final exact tree dc6dd2cd88390130523990acafeb71fe15218afc passed typecheck, Jest2/2, Vitest2796+1 existing skip, Chrome45/45 without retries, Firefox smoke and independent reviews. No store release or installed-extension update was performed. This issue remains open only for attended confirmation in the user's installed Pi session; synthetic browser coverage does not claim audible live confirmation. Real-host voice spend:0.