Recover recorder after audio device changes

[luckybucky9]

What

Rebuilds the audio engine when the audio device landscape changes, so dictation keeps working after a Bluetooth headset connects, an iPhone Continuity mic appears, Teams/Zoom register their virtual devices, or a USB mic is replugged.

Why

The engine is created once (prewarm() at startup) and reused for every recording. When a device change invalidates it, the failure is completely silent: the hotkey fires, the status bar animates, a recording file is created — but the tap delivers zero buffers. Whisper transcribes an empty WAV and nothing is typed.

On my machine (two USB mics + Bluetooth headset + iPhone + Teams/Zoom, so the device list churns all day) I found 19 recording files all frozen at exactly 4096 bytes — a WAV header and no audio — clustered around device-change times, across several days. A daemon restart cures it every time, which is the tell that the engine binding, not the mic, is stale. I believe this is also what the AirPods comment in human37#46 is describing ("open-wispr regularly just can't hear me despite airpods being connected"). human37#83 fixed exactly this failure mode for sleep/wake; this covers the device-change trigger, reusing the same machinery.

How

Two complementary recovery signals, both funneled into the existing reload() path:

1. AVAudioEngineConfigurationChange (the engine actually died, possibly mid-recording): cancel the in-flight recording, discard the partial file, reset the status bar, rebuild. Mirrors the systemWillSleep path. Observer is registered per-engine in prewarm() and removed in teardown(), so reloads never leak or double-register.

2. CoreAudio listeners on kAudioHardwarePropertyDevices + kAudioHardwarePropertyDefaultInputDevice (topology changed while idle): re-resolve the configured device UID against the devices that exist now and rebuild proactively. Debounced 0.5s because a single Bluetooth connect fires several events. In testing the engine usually survives a topology change while running, so an in-flight recording is not cancelled for this — the rebuild is deferred until the recording stops (reloadRecorderAfterRecording), and the notification in (1) catches the case where the engine genuinely died.

RecordingLifecycle gains audioConfigurationChanged(isReady:) so the decision logic stays pure and testable, matching the sleep/wake actions.

Testing

• swift build clean, swift test — all 126 tests pass, including two new RecordingLifecycle cases (cancel-while-recording, prepare-only-when-ready).
• Verified the CoreAudio listeners fire on this machine (macOS 26 / M5) when the default input switches, with a standalone harness using the same API calls.
• Reproduced the original failure fingerprint (header-only 4096-byte WAVs) from the field before the fix; after a daemon restart with a fresh engine, recordings capture normally.

🤖 Generated with Claude Code