Rebuild incremental context after marking PCM unavailable

This captures effectiveDefaultOutputFormat into IncrementalSpeechContext.outputFormat only once, but incremental playback reuses the same context while the directive is unchanged. When speakIncrementalSegment later sets pcmFormatUnavailable = true after a PCM failure, subsequent incremental segments still use the stale PCM format and keep incurring failed PCM attempts before MP3 retry. In long streamed replies, this defeats the intended session-level fallback and adds repeated latency/API calls.

Useful? React with 👍 / 👎.

The pcmFormatUnavailable flag is set here when PCM playback fails, but the cached IncrementalSpeechContext is not invalidated. When updateIncrementalContextIfNeeded is called for the next segment in the same streaming response, it returns early if the directive hasn't changed (line 1468), leaving incrementalSpeechContext.outputFormat set to PCM. This means each remaining segment still requests PCM, fails, and retries — the behavior this PR aims to eliminate.

The optimization only takes effect at the next assistant turn when a new context is built via buildIncrementalSpeechContext, which correctly uses effectiveDefaultOutputFormat.

To fully honor the "persist fallback choice for session" goal for mid-stream segments, consider invalidating the cached context when the flag transitions:

self.pcmFormatUnavailable = true
self.incrementalSpeechContext = nil   // force rebuild on next segment
self.lastPlaybackWasPCM = false

This approach ensures fallback is applied immediately to remaining segments in the current response.

This is a comment left during a code review.
Path: apps/ios/Sources/Voice/TalkModeManager.swift
Line: 1597-1601

Comment:
The `pcmFormatUnavailable` flag is set here when PCM playback fails, but the cached `IncrementalSpeechContext` is not invalidated. When `updateIncrementalContextIfNeeded` is called for the next segment in the same streaming response, it returns early if the directive hasn't changed (line 1468), leaving `incrementalSpeechContext.outputFormat` set to PCM. This means each remaining segment still requests PCM, fails, and retries — the behavior this PR aims to eliminate.

The optimization only takes effect at the *next* assistant turn when a new context is built via `buildIncrementalSpeechContext`, which correctly uses `effectiveDefaultOutputFormat`.

To fully honor the "persist fallback choice for session" goal for mid-stream segments, consider invalidating the cached context when the flag transitions:

```swift
self.pcmFormatUnavailable = true
self.incrementalSpeechContext = nil   // force rebuild on next segment
self.lastPlaybackWasPCM = false
```

This approach ensures fallback is applied immediately to remaining segments in the current response.

How can I resolve this? If you propose a fix, please make it concise.

pcmFormatUnavailable is reset to false before the network request completes. If gateway.request throws (network error, timeout, etc.), the flag is already cleared. The next TTS call will then attempt PCM again even though the subscription status has not actually been re-confirmed, potentially causing an unnecessary PCM round-trip and immediate fallback.

Consider resetting the flag only after a successful response:

func reloadConfig() async {
    guard let gateway else { return }
    do {
        let res = try await gateway.request(
            method: "talk.config",
            paramsJSON: "{\"includeSecrets\":true}",
            timeoutSeconds: 8
        )
        // Reset here after confirming successful response
        self.pcmFormatUnavailable = false
        // ... rest of processing
    } catch {
        // Flag remains set if reload fails
    }
}

If re-probing on every reload attempt (including failures) is intentional, a comment explaining the rationale would help.

This is a comment left during a code review.
Path: apps/ios/Sources/Voice/TalkModeManager.swift
Line: 1936-1939

Comment:
`pcmFormatUnavailable` is reset to `false` before the network request completes. If `gateway.request` throws (network error, timeout, etc.), the flag is already cleared. The next TTS call will then attempt PCM again even though the subscription status has not actually been re-confirmed, potentially causing an unnecessary PCM round-trip and immediate fallback.

Consider resetting the flag only after a successful response:

```swift
func reloadConfig() async {
    guard let gateway else { return }
    do {
        let res = try await gateway.request(
            method: "talk.config",
            paramsJSON: "{\"includeSecrets\":true}",
            timeoutSeconds: 8
        )
        // Reset here after confirming successful response
        self.pcmFormatUnavailable = false
        // ... rest of processing
    } catch {
        // Flag remains set if reload fails
    }
}
```

If re-probing on every reload attempt (including failures) is intentional, a comment explaining the rationale would help.

How can I resolve this? If you propose a fix, please make it concise.

Apply session fallback when default output format is PCM

This still gives precedence to directive?.outputFormat ?? self.defaultOutputFormat, so once pcmFormatUnavailable is set, the MP3 fallback is skipped whenever config has an explicit outputFormat like pcm_44100 (loaded into defaultOutputFormat in reloadConfig). In that setup, each new utterance retries PCM, fails, and then retries MP3 again, which defeats the intended session-level fallback and adds repeated latency/API calls.

Useful? React with 👍 / 👎.

Preserve PCM fallback across turns when reloading config

Resetting pcmFormatUnavailable at the start of reloadConfig clears the session-level fallback on every config refresh, and processTranscript calls reloadConfig() before each assistant reply. In environments where ElevenLabs rejects PCM, this causes every turn to retry PCM and incur the same failed request + MP3 retry latency instead of persisting the fallback for the active session. Reset should happen only after a successful re-probe/config change, not unconditionally on each reload call.

Useful? React with 👍 / 👎.

Preserve backpressure when wrapping PCM streams

monitorStreamFailures forwards rawStream through a new AsyncThrowingStream driven by a separate Task, which uses the default unbounded buffering policy. That removes backpressure between playback and network reads, so on long responses the producer can enqueue audio chunks much faster than the PCM player consumes them, causing avoidable memory growth (and potential jetsam on lower-memory devices). Keep producer/consumer coupled or use a bounded buffering policy when proxying chunks.

Useful? React with 👍 / 👎.