[Bug]: macOS records the default microphone when the chosen one carries a Chromium suffix like (Virtual) #1143

What happens

On macOS, a microphone picked explicitly in the HUD's Device settings is not resolved by the ScreenCaptureKit helper when Chromium labels it with a transport suffix such as (Virtual), (Built-in), (Bluetooth) or (Aggregate). The take records the system default input instead, and the user gets the toast "The chosen microphone could not be identified. Recording the default input."

Found in the v2.1.0 candidate e2e pass (release/v2.1.0 @ 9c55596, build run 38252812147, results in #1131).

Repro

1. macOS 15+ with two audio inputs, one of them a virtual device (here BlackHole 2ch).
2. HUD gear: pick BlackHole 2ch (Virtual) (not the Default - ... entry), microphone on.
3. Record a take.

Main-process log, on every take:

[native-sck] recording the default input; microphone was not resolved { deviceId: '40657edc...', deviceName: 'BlackHole 2ch (Virtual)' }

AVFoundation lists the same input as uniqueID BlackHole2ch_UID, localizedName BlackHole 2ch.

Why

resolveMicrophoneDeviceID (electron/native/screencapturekit/Sources/OpenScreenCaptureCore/MicrophoneDeviceSelection.swift) matches the label exactly, and the only decoration it removes is the USB (vvvv:pppp) pair added in #648. Chromium's GetDeviceLabel appends one suffix per CoreAudio transport type too, so a virtual, built-in, Bluetooth or aggregate input never matches its localizedName. The existing test even pins Shure MV7 (Virtual) as unresolvable.

Expected vs actual

• Expected: the chosen input is recorded, with no fallback toast.
• Actual: the default input is recorded. On the test Mac this went unnoticed in the audio because BlackHole is also the default input; with a different default the wrong microphone is recorded.

Platform

macOS 26.5, Apple Silicon. The Windows path is separate and not affected.