Multi-hour Windows TCI-to-local-mic soak: confirm the WASAPI capture residue stays bounded

Why this exists

PR #4958 fixes a repeatable Windows access violation after multi-hour TCI transmit sessions (Microsoft Store v26.8.2, two independent minidumps resolving to TxMicChannelNormalizer::canonicalizeInt16ToMonoStereo() via AudioEngine::onTxAudioReady()).

The root cause is confirmed and the fix is layered — the pull-mode read is bounded, the capture path drops to latest, and the normalizer validates before any dereference or allocation. Every item on that PR's test plan is green except the one that cannot be run in CI: a real multi-hour soak on Windows hardware.

This issue exists so that soak has somewhere to land, and so affected Store users can find the status. GOVERNANCE.md exempts a bug fix with a clear root cause from needing an issue first, so #4958 is not blocked on this — it is the follow-up verification.

What to run

1. Windows, 48 kHz stereo Int16 TX input, microphone capture active.
2. A TCI client supplying fresh TX audio continuously (WSJT-X is the reference client).
3. Leave it running three hours or longer.
4. Return TX ownership to the local mic path.

What to check

Read the automation bridge's get audio TX endpoint during and after the run:

• buffer_bytes_available — must stay near zero throughout. This is the residue that grew unbounded before the fix.
• capture_backlog_discards / capture_backlog_discarded_bytes — must stay zero on a healthy run. Non-zero means the drain is not keeping up and capture had to skip stale audio to return to realtime; the residue is bounded either way, but it means the drain half of the fix is not doing its job.
• saturation_observed, full_buffer_during_tci_observations, idle_during_tci_transitions — no new saturation events.
• No rejected oversized TX mic block warnings in the log.
• Process working set should be flat, not climbing.

Capture-health summaries are gated behind Help → Support's TCI / CAT / rigctld logging toggle; enable it before the run.

Also worth soaking

• macOS, for the same window. #4958 extended the TCI-suppression drain to the macOS push buffer, which previously grew at ~192 KB/s for the whole session in the app's own resident memory. A long TCI session should now show flat memory.
• Low-rate TCI clients (audio_samplerate=8000 / 12000). These expand up to twelvefold across the upsample to 24 kHz, and are the reason the float32 route carries a larger validation ceiling than the mic route; worth confirming a real 8 kHz client transmits cleanly.

Links

• PR #4958
• docs/architecture/audio-pipeline.md — capture/backpressure contract
• docs/automation-bridge.md — the capture-health metric definitions

Start with docs/architecture/audio-pipeline.md and docs/automation-bridge.md, then run the stated three-hour Windows TCI soak with WSJT-X and inspect the automation bridge's get audio TX endpoint. Done means bounded buffer residue, zero backlog discards and new saturation events, no oversized-block warnings, and a flat process working set; the optional macOS and low-rate client runs provide additional verification.