Make the input-device settle gate survive sleep, which it never did

[missingbulb]

Fixes the no-signal wedge recurrence reported on 0.5.0 after a sleep: menu bar on ⚠️, System Settings → Sound → Input meter dead — the same system-wide shape as #88, with the settle gate #88 added in place and doing nothing at all on the wake path.

What was wrong

requireSettledInputDevice() asks AudioDiagnostics how long a usable input device has been continuously present and refuses to open one that has not settled for 6s. But the sampling timer does not fire while the machine is asleep, and usableInputSince was carried straight through that gap. A mic that powered down, re-enumerated and came back was still reported as continuously present since before the sleep — as a long elapsed run in 0.5.0, as .greatestFiniteMagnitude via witnessedArrival == false after #101.

Either way the gate passed instantly and the wake resume opened the device with zero settle: precisely the "opened it in the same second it appeared" hazard the gate exists to prevent, on precisely the transition it was built for.

The fix

A duration is a claim about a span you observed, so a blind spot inside the run invalidates the run. AudioDiagnostics now tracks observation as its own state:

• usableInputFor: TimeInterval? → inputAvailability, a three-state enum. .absent ("no default input worth opening") and .unobserved ("we have not been watching") are different answers and only one is about the hardware. Collapsing them would have put an unmeasured claim about the mic into the log — the sin Mic dead system-wide after sleep while the app claims it is listening #79 and Mic wedges system-wide after sleep while the app still holds it — root cause unconfirmed #88 were both about.
• noteObservationInterrupted() is called from willSleep, so a sleep is declared rather than inferred. Inferring from elapsed time misses a sleep shorter than the tolerance, and the USB bus is powered down for a short sleep too. An elapsed-time backstop in sample() covers interruptions nobody announces — measured with Date(), not systemUptime, the one place in this file that inverts the usual rule: the monotonic clock by design refuses to count the very span at issue.
• The run is keyed on the device's UID, so a mic swapped for another between two samples restarts the clock instead of inheriting the run of the device that just left. A set-level "is anything usable?" predicate cannot see that happen at all.
• usableInput() judges the system default input — the device AVAudioEngine actually opens. A healthy mic behind a broken default is not a mic we can capture from. This also subsumes the old exclude-aggregates rule (our hidden CADefaultDeviceAggregate is never the system default) and fixes its collateral damage: a user's deliberately-built aggregate device is a fine thing to capture from, and the old predicate refused it.

Version bumped to 0.5.2 (build 12) so the fix ships as its own Release rather than refreshing v0.5.1 (#74).

Behaviour

Path	Before	After
Launch, mic already present	settled, starts immediately	unchanged — #101's fix stands
Display sleep (system awake)	device vanishes/returns, witnessed, 6s settle	unchanged
System sleep → wake	gate passes instantly, opens with no settle	.unobserved → refuse → first post-wake sample re-establishes a witnessed arrival → full 6s settle

Post-wake, the retry ladder lands the start ~8–15s after wake instead of ~3s. Refusals are free — requireSettledInputDevice() throws on a HAL property read, before anything builds an AVAudioEngine or opens a device.

What this does and does not prove

It does not prove the mid-enumeration theory. What it settles is narrower and worth keeping separate: the mitigation shipped in 0.5.0 was never actually exercised on the wake path, so 0.5.0 recurring says nothing about whether the mitigation works. The next recurrence is the first one that will.

The reporting side did work as designed — the ⚠️ no-signal state from #100 is what made this diagnosable from a menu-bar screenshot instead of a log reconstruction.

Testing

CI builds the DMG (swift build runs there; no macOS toolchain in the session). Per dev/procedures/mac-audio-lifecycle.md, compile-green is explicitly not a gate for this file — the change is not verified until the app has actually started on a Mac and been slept. Suggested check on the owner's Mac: install 0.5.2, pmset sleepnow, wake, and confirm the activity log shows a refusal (the input device has not been watched since the machine slept and/or input device appeared Ns ago) followed by listening started within ~15s.

Lesson captured in dev/procedures/mac-audio-lifecycle.md.

---

Generated by Claude Code