Stop writing the Mac-wide default input per dictation; fix Bluetooth start latency and route churn

[r3dbars]

Problem

Dictation over AirPods/Bluetooth was flaky: mic-start retries, fast starts falling back to a ~1.1–1.5s readiness wait, audible artifacts in music playback around dictation, and the system default input visibly flip-flopping between the AirPods and the built-in mic. A deep audit (13 parallel code sweeps + log forensics + git archaeology, then 3-lens adversarial verification of 8 hypotheses) confirmed four interacting root causes — all app-side.

Root causes → fixes

1. Per-session Mac-wide default-input override (H1). Every Bluetooth-fallback dictation wrote kAudioHardwarePropertyDefaultInputDevice → built-in at start and restored the AirPods at stop — two machine-wide HAL writes per dictation, independent of any setting, while the per-process AUHAL bind already did all real capture work. Log ground truth: 53 writes and 29 default-input changes in one day; BT-route start median 441ms / p90 1011ms vs 86ms on built-in routes. Fix: removed the write, the restore-arming, and the orphaned temporary crash-marker plumbing. The owner-lease restore seams in ParakeetSystemInputCoordination remain as deliberate no-ops.
2. Prewarm faked readiness on exactly the Bluetooth-fallback route (H2), publishing inputFormatReady=true with zero hardware work, so starts attempted a doomed fast path (~420ms) then paid the deterministic wait-loop floor (logged 1089–1523ms). Fix: deleted shouldDeferHardwarePrewarm/shouldDeferHardwareRecovery; prewarm and idle recovery now always do the real AUHAL bind + verified format read (safe now that this implies no Mac-wide write).
3. The untracked writes killed the "Faster Bluetooth dictation" feature (H6). They bypassed self-write detection, so PersistentDictationInputController misread them as user mic choices and permanently relinquished ownership mid-session. Logs: 0 flaky starts in the 4h45m the feature ran; 24 in the hour after it silently died. Fix: closed by construction — dictation performs no Mac-wide writes at all now.
4. hfp_suspected telemetry was structurally blind (H3) to fully-switched HFP (both legs ≤24kHz — confirmed live false negative) and 0-rate unsettled reads, and the settle/failure events never carried the field. Fix: widened the heuristic (unmeasured nil rates still report false) and added hfp_suspected to audioFormatContext events. Side effect (intended): silent-callback zombie resets now also trigger on fully-switched HFP routes.

Rejected after verification against real logs: macOS auto-switch as primary driver, stale-marker launch restore, HFP recovery recordings, idle-poisoning cadences.

Guardrails

• Tests/BluetoothRouteContractTests.swift now pins the negative invariant: audioInputSnapshot must never contain a system default-input write; the retired temporary marker may not be reintroduced. New suite covers the widened HFP cases.
• Sources/Speech/CLAUDE.md documents the invariant and its rationale.
• scripts/dev/bluetooth-route-metrics.py compares post-fix route health (start-latency distribution, write counts, retry/fallback counts) against the captured pre-fix baseline, with a loud regression tripwire.

Verification

• bash build.sh --no-open — clean
• bash run-tests.sh — 12,195 passed, 0 failed
• bash scripts/dev/agent-preflight.sh — confirms the above is the required set for this diff
• ⚠️ Live AirPods go/no-go still pending (no CI exercises Bluetooth hardware): repeated dictation cycles with music playing — expect no default-input flips, starts well under the old 1.1–1.5s floor, no audible artifacts, and correct transcripts. Pre-recorded fallback if format negotiation fails on the AUHAL-only bind: restore-after-successful-start variant.

Net −128 lines (277+/405−): a removal-shaped fix.

🤖 Generated with Claude Code