fix(parakeet): restart capture on mid-session input-device configuration change

[initcore0]

Reported symptom

Mid-dictation with Parakeet, the app stops producing words (~a minute in), then "comes back" later — with the words spoken during the gap permanently missing.

Investigation: no regression in the decode path

• FluidAudio is pinned at 0.15.5 since the original integration (feat(engine): Parakeet realtime engine — full integration (MAK-46) #163) — the decoder hasn't changed.
• The recent Parakeet-adjacent changes (#218, #222) only touch stop-time callback snapshots and the final-transcript "You" strip — neither is in the mid-session flow.
• A real-model harness (drives StreamingUnifiedAsrManager with the app's exact 320ms [70,2,2] config over 2.5 minutes of continuous fixture speech, fed in the app's 1024-frame buffers) sustained RTFx 5.5 with zero dropout windows — even transcript growth in every 10s bucket, all 60 repetitions of the fixture phrase present in the final. The decoder does not go deaf on its own.

Root cause

A mid-session AVAudioEngineConfigurationChange (input device disconnected/switched/format renegotiated — USB mic glitch, device pinning fallback, another app grabbing the device) stops AVAudioEngine's rendering. The streaming engines never observe the notification, so the session keeps showing "Listening…" while capturing nothing — every word until the user re-dictates is silently lost, and there is no error.

AudioRecorder has handled exactly this since the AirPods-disconnect hang (its comment: "the session keeps showing 'recording' while capturing nothing"); the streaming engines were never given the observer. Parakeet only recently became the default engine, and long dictations only recently became routine (same reason #222's WhisperKit 30s truncation surfaced late) — which is why this reads as a new bug.

Fix

• Seamless restart, not fail-only: the decode session and feed stream survive the mic teardown, so on the notification the engine rebuilds a routed AVAudioEngine + tap onto the same continuation and the dictation continues. Everything already captured stays; only the glitch itself is lost. If the rebuild fails (no input device left), the session fails loudly through the error path.
• Decision gates extracted to core (CaptureConfigChangePolicy) so swift test pins them: restart only when the session generation matches and no stop ran; stale/superseded notifications touch nothing.
• Route/format setup extracted into makeRoutedEngine() / startCapture(), shared by session start and restart (start-path behavior and error messages unchanged).
• Observer is selector-based on purpose: the block API takes a hard @Sendable closure and every capture the restart needs is non-Sendable — this keeps the file at zero warnings.

Testing

• swift test: 1904 passing (4 new in CaptureConfigChangePolicyTests).
• ./build.sh (WhisperKit + Parakeet): green, no new warnings vs baseline.
• Real-model streaming harness: 2.5 min continuous audio, no dropouts (evidence for "no decode regression" above).

⚠️ Same caveat as #222: the restart path only exercises against a real device change — worth a live pass (unplug/replug the pinned mic mid-dictation, or trigger a format change) before the next release.

Follow-ups (not in this PR)

• WhisperKitStreamingEngine / AppleSpeechEngine / SpeechAnalyzerStreamingEngine have the same missing observer.
• stopAppleSpeech's 2.0s stuck-session fallback can clobber a slow Parakeet finalize (feed-drain + finish() > 2s) with a stale partial and drop the genuine final — a second, independent path to "missing tail words".

🤖 Generated with Claude Code