fix(audio): mute the host's voice when SayPi is the one speaking (#602)

[rosscado]

Fixes #602.

The symptom

With a SayPi voice selected on pi.ai, both voices play at once — ours, and Pi's own over the top. Only visible since #597; before that we produced no audio at all, so the missing mute looked like the whole bug.

Why

AudioOutputMachine already owns the decision. On the audio element's loadstart it sees a source belonging to neither the selected voice nor the active provider, and skips it.

It never got the chance, because AudioModule had no element bound at all. Measured live on pi.ai:

[AudioModule] Using offscreen audio: true
Audio Output Machine transitioned from N/A to idle
Audio element removed from the document      <-- the tracked element goes
Cleaned up audio element
Speech provided by Say, Pi                   <-- provider IS SayPi

…and afterwards the page held two <audio> elements, one audibly playing pi.ai/api/chat/voice, neither carrying saypi-audio-main.

The recovery path was the gap: losing the element re-armed listenForAudioElementSwap(), an observer that fires only for newly added subtrees. pi.ai replaces its player rather than reusing it, so the replacement was already in the document and nothing was ever added afterwards to react to. The observer waited forever and the binding was lost for the life of the page.

The change

Both parts serve one rule — when a SayPi voice is selected, SayPi is the TTS provider, so the host is silent and we speak:

1. Recovery takes up an element that is already there, and only waits for an insertion when there genuinely is none.
2. The mute is an invariant, not a reaction. Held from the active provider and re-asserted whenever the element or the provider changes, so a track the host started before we bound to it can't stay audible for its whole length. Gated on offscreen playback: without an offscreen document (Firefox, Safari) SayPi shares that element and muting it would mute us, so skip-on-loadstart remains the whole mechanism there.

Muting rather than pausing is deliberate — the host's player keeps its own state and its UI doesn't fight us over it.

The decisions live in src/audio/hostAudio.ts because AudioModule.js can't be imported by a test (the same reason audioElementRemoval.ts exists); the wiring is pinned by the source-scanning guards beside it.

Verified on the live host

Layer 4 (CDP), real pi.ai, signed in, a SayPi voice selected — the fix does what the unit tests can only imply:

Audio element removed from the document
Cleaned up audio element
[AudioModule] Rebinding to the host's audio element
Speech provided by Say, Pi
[AudioModule] Muting the host's audio element

Sampled every 1.5s across a full turn, Pi's own player reads id=saypi-audio-main, bound=true, muted=true, src=https://pi.ai/api/chat/voice throughout — including one sample where it was actively playing while muted, which is exactly the race the invariant exists for: the host started that track without a loadstart we could have skipped.

tsc --noEmit, Jest and 2676 Vitest tests green.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KgkAqzyjN5xtxR5fKxRPR2