Add editable microphone rules and explained device type detection

[Wolbyworld]

Add opt-in microphone selection rules with an editable type order, per-type lid conditions, and saved device-type overrides. For example, users can prefer a headset, then the Mac microphone with the lid open, then a camera microphone with the lid closed.

Draft: model tests, native controls, and real-device route checks pass. Lid transitions, physical reconnects, and audible input still need the hardware UAT in Tests/UAT.md.

Motivation

Moving the same laptop between workstations changes which microphones are available. A user may prefer a headset at one desk, an external microphone at another, and the built-in microphone while travelling. Maintaining only a list of individual devices makes that preference harder to apply when a new microphone is connected.

These rules automatically select the highest-priority available microphone using the user's preferred device types and lid conditions. The user defines that order based on their setup and sound-quality preferences; the app does not measure or rank audio quality. This proposal does not add workstation profiles or settings sync between Macs.

Behavior

• Microphone automation… opens a separate window that remains open after the menu closes.
• Rank microphone types and choose Always, Lid open, Lid closed, or Never.
• Detect types from CoreAudio transport and input terminal metadata, then use limited, explained name hints. USB alone does not imply a headset.
• Override a device type or select Auto to clear the override. Rules and UID-based overrides persist.
• Rules default to off. Custom mode pauses automatic switching; Ignore and Never Use still apply. Existing device priority breaks ties within a type.
• Output selection and the existing popover sizing are unchanged. The separate layout proposal is Fix collapsed menu popover within available screen height #37.

GUI

The entry remains accessible above the existing device list, even on a system with the pre-existing list-collapse issue:

Editable rules, shown with an example lid configuration:

Automatic classifications with their evidence, including a remembered disconnected Bluetooth device:

Manual type override

The camera is explicitly assigned a type here; selecting Auto restores detection.

Screenshots come from the native preview built from this PR's source, with a separate bundle identifier and Custom mode enabled. Screenshot files are hosted on the fork's documentation branch and are not part of this code diff.

Validation

• sh Tests/run.sh: 52 classification, selection, normalization, and persistence checks passed.
• Universal arm64/x86_64 Release build passed.
• Native UI: fresh rules defaulted off; the settings window opened independently of the menu; type reordering, lid-condition edits, and a saved camera override were checked.
• Observed built-in, USB webcam, Continuity, and Bluetooth classifications. The Bluetooth device also appeared as disconnected when it became unavailable.
• Real-device route UAT on a MacBook Air with a USB StreamCam: 15 checks passed using the PR's production AudioManager and CoreAudio service in an isolated local test runner. Checks covered switching between camera and built-in input, rule edits while in Custom mode, leaving Custom mode, Ignore and Never Use in Edit mode, all types excluded, type overrides and device-priority tie breaks, and disabling rules. Each check read back the system default input and confirmed that the system default output stayed unchanged. No audio was captured. The starting routes and app settings were restored after the run.
• Bounded standard code review of the feature and the scope correction completed with no actionable findings.

Detection is advisory where metadata is incomplete. A changed driver UID can require a new override, and metadata does not prove a wireless dongle's headset link is active. If no rule qualifies, the current input stays unchanged. Lid transitions, physical disconnect/reconnect behavior, and audible-input checks remain pending. The route checks establish system default-device changes, but do not establish capture or audible sound.

Split from closed #36. This proposal contains no popover height fix.