downmix multichannel capture to stereo

## Problem When the captured audio device delivers more than 2 channels (Logitech PRO X Wireless 7.1 in #56, Bose Companion 2 Series III with a 6-channel loopback mix, or any 5.1/7.1 device), `swyh-rs` writes the raw N-channel interleaved bytes into the stream while every encoder, WAV/RF64 header, LPCM Content-Type, UPnP ProtocolInfo, and DIDL nrAudioChannels is hardcoded to 2. The renderer reads bytes assuming stereo frames and plays the result at ~N/2× speed with heavy distortion. ## Proposed Solution Downmix any non-stereo capture to interleaved stereo at the wave_reader / wave_reader_f32 seam, before samples reach the streaming clients. The rest of the pipeline (already stereo-only by design) stays self-consistent. Stereo input takes a zero-overhead fast path. Coefficients follow [ITU-R BS.775-4](https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.775-4-202212-I!!PDF-E.pdf) - the broadcast/Blu-ray standard, also used in ffmpeg's more advanced [`libswresample`](https://github.com/FFmpeg/FFmpeg/blob/master/libswresample/rematrix.c): * `L = FL + 0.7071 × FC + 0.7071 × BL + 0.7071 × SL` * `R = FR + 0.7071 × FC + 0.7071 × BR + 0.7071 × SR` LFE is dropped, output is clamped to ±1.0 to avoid overflow in samples_to_i32. Mono input is duplicated to L=R. `WavData.channels` is now 2 post-downmix so the RMS monitor reads correct L/R. The downmix output buffer is captured by the audio callback closure and reused across calls (matching the existing f32_samples pattern in the same module) - no per-callback allocation on the hot path. - Fixes #56. ## Verification - Successfully tested in practice with Bose Companion 2 (5.1 channels) and Sonos Play:1. - New unit tests cover passthrough, mono duplication, BS.775 math, clamping, multi-frame iteration, and buffer reuse.