fix: Web Audio streaming playback — fixes Safari NotSupportedError

Operator confirmed the "TTS blocked" was NotSupportedError on Safari — WebKit refuses a
streaming 0xFFFFFFFF-length WAV via <audio src> (can't compute duration/seek), exactly
as infra-ops warned. Replaced the <audio src> playback with a Web Audio path that works
in all engines:

- speakOnDone: fetch the chunked /api/tts stream, skip the WAV header to the data chunk,
  decode int16 LE PCM -> Float32, and schedule the samples GAPLESSLY into an AudioContext
  as they arrive (BufferSource per chunk, playAt += buf.duration). Progressive, TTFA
  ~0.5s. Decoding the raw PCM ourselves sidesteps every WAV-container quirk.
- unlock: an AudioContext starts suspended; Safari + Chrome need resume() from a user
  gesture. _unlockTtsAudio() now resumes the ctx on the first interaction anywhere +
  toggle-on + submit, so it's running before the ~15s-delayed speak-on-done.
- cancelTts: aborts the fetch + stops all scheduled BufferSource nodes.

Validated in Chromium (Playwright, strict autoplay): 43 nodes scheduled, 5.1s of PCM
decoded, ctx "running" 6.5s post-gesture, zero errors. Headless WebKit can't launch here
(missing system libs — an infra-ops install), so the operator's live Safari is the final
check; the code is standard Web Audio Safari has supported for years.

Contract FN client:speakOnDone updated (Web Audio; the Safari NotSupportedError reason).

docs/contracts/donut_voiced_interview.contract.md

@@ -201,19 +201,26 @@ pin_kb_context(question: str, agent_id: str | None, *, client) -> list[dict]   #
               searches in-voice natively.
 ```
 
-### FN client: speakOnDone  (index.html — STREAMING, DEC-2)
+### FN client: speakOnDone  (index.html — Web Audio STREAMING, DEC-2)
 ```
 on SSE `done`:
   if !ttsEnabled(): return                                  # INV-TTS-2
-  cancelTts()                                               # INV-TTS-3: audio.pause()+removeAttribute(src)+load()
-  audio.src = "/api/tts?text=&agent_id=&p=&a="              # GET streaming URL (text sliced to the 2000 cap)
-  audio.play()  -> ▶ voiced ; .catch -> "playback blocked"  # progressive; failure non-fatal (INV-TTS-4)
+  cancelTts()                                               # INV-TTS-3: abort fetch + stop scheduled nodes
+  fetch("/api/tts?text=&agent_id=&p=&a=") -> reader         # chunked stream (text sliced to the 2000 cap)
+  loop: read chunk -> skip WAV header up to the data chunk -> int16 LE PCM -> Float32 -> AudioBuffer ->
+        BufferSource.start(playAt) scheduled GAPLESSLY -> playAt += buf.duration   # progressive, TTFA ~0.5s
+  first scheduled node -> "▶ voiced"; any failure -> ticker + skip (INV-TTS-4)
 
-AUTOPLAY UNLOCK (the load-bearing fix for "no audio"): speak fires play() in an async callback seconds after
-the keypress, past the browser's transient-activation window, so a bare play() is blocked. _unlockTtsAudio()
-plays a tiny silent WAV inside a REAL gesture (toggle-on + each prompt submit), which grants the <audio>
-element a PERSISTENT "may-play" flag so the later streaming play() isn't refused. Validated in Chromium with
---autoplay-policy=document-user-activation-required: play succeeds 6.5s after the gesture, currentTime advances.
+WHY Web Audio, not <audio src>: Safari/WebKit REFUSES a streaming 0xFFFFFFFF-length WAV via <audio src>
+(NotSupportedError — it can't compute duration/seek), which was the operator's live failure. Decoding the raw
+int16 PCM ourselves and scheduling it into an AudioContext sidesteps every WAV-container quirk and works in all
+engines. Validated in Chromium: 43 nodes scheduled, 5.1s decoded, no error.
+
+AUTOPLAY UNLOCK: an AudioContext starts "suspended"; Safari + Chrome require resume() to originate from a user
+gesture (then it stays running). _unlockTtsAudio() resumes it on the FIRST interaction anywhere (document
+pointerdown/keydown) + toggle-on + each submit, so it's running before the ~15s-delayed speak-on-done. Validated:
+ctx is "running" 6.5s after the gesture (past the transient-activation window). Page served no-store so a stale
+cache can't hide these updates.
 ```
 
 ## Slice plan