fix: follow changed default microphone

[kaynansc]

Before Submitting This PR

• I have searched existing issues and pull requests (including closed ones) to ensure this isn't a duplicate
• I have read CONTRIBUTING.md

If this is a feature or change that was previously closed/rejected:

Not applicable. This is a bug fix for a separately reproduced default-device transition; it does not reopen a closed feature proposal.

Human Written Description

When Handy is set to Default, changing the macOS input can leave it listening to the previous microphone. This update detects the change and reopens the audio stream before the next recording, so the new default microphone works without restarting Handy.

Related Issues/Discussions

No public issue has been filed for this exact default-device transition.

Related: #1715 and #1716 cover the main-thread audio freeze that made the old reset workaround beachball. #1874 covers physical microphone disconnects; this PR instead handles a live system-default change while the existing stream remains healthy.

Community Feedback

The bug was reported from a real macOS workflow using Default, Always-On mode, Bluetooth AirPods, and other microphones. It was reproduced locally against v0.9.4 before implementing the fix. No public discussion exists yet for this exact case.

Testing

Root cause: with Always-On enabled and selected_microphone = None, Handy kept the stream opened on the device that was default at startup. Changing the macOS default left that healthy stream attached to the old microphone. Opening the dropdown only refreshed its options, and resetting to Default was the only path that restarted capture.

What changed:

• Track the concrete device behind the open recorder stream.
• Before the next recording, cheaply compare that device with the current system default and reopen only when Default is selected.
• Reconcile the same mismatch when the microphone list is refreshed, while refusing to interrupt an active recording or override an explicit device choice.
• Keep blocking CoreAudio work on the existing spawn_blocking command path.

Automated checks:

• rustc --test src/managers/audio_device_refresh.rs — 5 passed
• cargo test --lib --locked — 182 passed
• cargo clippy --all-targets --locked — passed with existing warnings outside this change
• bun run lint — passed
• bun run build — passed
• bun run format:check — passed

Manual macOS validation:

1. Baseline v0.9.4, Always-On + Default: changed the input default from Stealth 700P Gen 3 to AirPods and started recording without reset. The log had no new Using device, confirming capture remained on the old stream.
2. Corrected debug build: changed the input default from Stealth 700P Gen 3 to MacBook Pro Microphone and started recording without reset.
3. The log showed System default microphone changed; reopening stream before recording, then Using device: Ok("Microfone (MacBook Pro)"), followed by a successful recording start. The app remained responsive.

AirPods became unavailable to CoreAudio during the corrected-build run, so the green hardware transition used the two input devices still present. It exercises the same default-device comparison and CoreAudio reopen path.

The debug Handy.app bundle built successfully with an ad-hoc signature. DMG packaging was stopped after the application bundle was complete because it was not needed for hardware validation.

Screenshots/Videos (if applicable)

No UI screenshot is needed; the regression is an audio-routing state mismatch. The before/after device names and reopen event were verified in handy.log.

AI Assistance

• No AI was used in this PR
• AI was used (please describe below)

If AI was used:

• Tools used: OpenAI Codex
• How extensively: Codex updated the stale checkout, reproduced and separated the already-fixed UI freeze from the remaining default-device bug, implemented the patch and regression tests, ran the validation suite, built the macOS app, and performed the local hardware transition test. The human contributor must provide the Human Written Description above before this PR is marked ready for review.