feat: record PC audio during online meetings

[piyton]

Closes #18.

The problem

Recording a meeting captured the default microphone and nothing else, so a Teams,
Zoom or Meet call produced a transcript containing only the local user. The
workaround was recording the call in OBS Studio first and transcribing the file
afterwards, which makes the built-in recorder pointless.

Two smaller defects sat in the same code path:

• settings.audio_device was written by the Settings UI and stored, but audio.rs
  never read it — it always opened host.default_input_device(). The dropdown did
  nothing.
• There was no way to tell whether meeting audio was arriving until the recording
  was over.

What changed

Record & Transcribe now asks whether the meeting is in-person (microphone
only) or online (microphone plus PC audio). Online opens a second cpal stream on
the render endpoint, which cpal turns into a WASAPI loopback client — it sets
AUDCLNT_STREAMFLAGS_LOOPBACK itself, so no new dependency was needed.

Dictation via the global hotkey stays microphone-only even while a meeting is
running, so a dictated sentence can never pick up whatever the machine is playing.

Why a timeline mixer

Appending samples as they arrive does not survive system audio. WASAPI delivers no
packets at all while nothing is playing, so every silent stretch would shrink and
the system source would slide ever further ahead of the microphone — badly out of
sync well before an hour-long meeting ends, and overlapping speech is exactly what
Whisper handles worst.

OBS Studio solves this in its mixer rather than its capture, and this PR does the
same. TimelineMixer (new, src-tauri/src/mixer.rs) addresses one shared 16 kHz
timeline by capture timestamp: gaps become silence, overlapping sources are summed
and clamped. Timestamps come from InputCallbackInfo::timestamp().capture, which
on WASAPI is an absolute QPC value, so both streams share one clock. The first
microphone packet anchors position zero. take() leaves a 300 ms tail so a packet
from the slower stream still lands in place when the recorder pulls a segment.

Also in this PR

• settings.audio_device is finally honoured, for meetings and dictation alike.
• New settings.system_audio_device plus a Settings → Audio → System audio
  device dropdown, for switching between headphones and speakers.
• A PC level meter beside the microphone meter, and a warning when no PC audio has
  arrived for 30 seconds — the failure you would otherwise only discover afterwards.
• A configured device that has been unplugged falls back to the platform default
  instead of failing the recording.

Failure handling

A meeting should never be lost to an audio error.

Situation	Behaviour
Loopback fails to open (macOS, Linux, no output device)	Logged; recording continues microphone-only and the UI says system audio is unavailable
Output device disappears mid-recording	Logged by cpal's error callback; the microphone keeps recording
No system packets for 30 s in online mode	Warning in the panel; recording continues

Testing

16 unit tests, all passing (cargo test --lib): the mixer's gap-to-silence,
out-of-order writes, summing and clamping, the drain margin, stale-write rejection;
plus device resolution and the downmix/resample helper.

One opt-in hardware test verifies the real thing on Windows — it renders a quiet
440 Hz tone on the default output and asserts the loopback stream picks it up and
reaches the mixed timeline:

cargo test --lib -- --ignored loopback

Verified passing on Windows 11. npm run build and tsc --noEmit are clean.

Not in this PR

Keeping microphone and system audio as separate tracks for speaker attribution
("me" versus "the others"). Attractive for minutes, but it doubles transcription
time and deserves its own design.

Design and plan: docs/superpowers/specs/2026-08-28-system-audio-capture-design.md,
docs/superpowers/plans/2026-08-28-system-audio-capture.md.

🤖 Generated with Claude Code