[silverstein]

Summary

Fixes #1219 (from #1114). Native call-capture stems are mono f32 at the device sample rate, so the 8 h default max_duration_secs can't stand in for a size cap: the 4 GB RIFF limit arrives after ~6.2 h at 48 kHz (the rate both reporters measured, ~192 KB/s) and ~3.1 h at 96 kHz. Past it, the capture needs a manual minutes recover-stem.

• New StemSizeGuard in minutes_core::capture: warns at 90%, then stops 64 MiB under u32::MAX (about 2.9 minutes of 96 kHz audio, far more than the 5 s check interval plus stop latency).
• The native capture loop checks the larger stem every 5 s via the existing session.stem_paths() and routes warnings/stops through the same notices and normal finalization as the time and disk guards, so the capture is still processed.
• Size-based, so it holds at any sample rate. No change to call_capture.rs or the Swift helper (open PR Recover microphone capture after an input disconnect #1210 is editing both).

Test plan

• cargo fmt --all -- --check, cargo clippy --all --no-default-features -- -D warnings
• cargo test -p minutes-core --no-default-features --lib capture:: (81 passed) including a new guard test (warn once, stop below the limit with headroom)
• cargo test -p minutes-app --no-default-features
• Full multi-hour native capture not exercised (the guard logic is unit-tested; the loop wiring mirrors the existing safety guard)

🤖 Generated with Claude Code