fix(threads): stop crossing thread boundaries in the RX and TX audio paths

[bucknova]

Three thread-affinity defects from the adversarial review.

This area has form — a cross-thread PortAudio abort corrupted the heap, and a
QThread destroyed while running triggered qFatal — so each change here is
narrow, and each carries a test that fails without it.

1. The audio-device swap reset the decoder from the wrong thread

_swap_audio_worker called RxWorker.reset() directly from the GUI
thread. The audio worker's stopped signal fans out to both
_rx_worker.flush (queued → RX thread) and the swap loop's quit (GUI), so
the GUI could wake and reset the decoder while a flush was still inside
Decoder.feed(), clearing _buffer / _scratch / _total_samples under a
live decode.

Worse, reset() lazily creates the RX watchdog QTimer, which takes the
affinity of whoever calls it. Created from the GUI thread, the watchdog then
ran its checks on the GUI thread while shutdown() — on the worker thread —
could no longer stop it (QObject::killTimer: Timers cannot be stopped from another thread), leaving a live timer firing into a worker being torn down.

The queued signal that does this properly, _request_rx_reset, was already
declared and already wired to that exact slot — ten lines above the direct
call. The swap now uses it, and orders the capture restart after the reset
rather than racing it on a second worker thread.

_ensure_watchdog_timer now refuses to create the timer when the caller
isn't the owning thread, so this can't regress quietly.

2. The start-capture one-shot ran on the RX decode thread

reset_done → _start_once was a bare closure. A plain callable has no
QObject affinity, so PySide invokes it in the emitting thread — the RX
decode thread — where it called sd.query_devices(), a process-global
PortAudio read that can run concurrently with the audio worker's own
_pa_reset, and wrote _input_device while the GUI thread read it.

Now a real slot on MainWindow, connected queued at construction, with an
armed flag instead of connect/disconnect bookkeeping. That also retires the
H7 workaround — a second click can no longer leave two closures connected and
start capture twice.

3. stop() could abort a stream that was being closed

It read _active_stream under the lock, released it, then called
abort(). The TX thread clears that pointer under the same lock and only
then lets its with sd.OutputStream(...) block run
Pa_StopStream/Pa_CloseStream — so the released window let
Pa_AbortStream land on a stream mid-close. sounddevice passes the pointer
straight to PortAudio with no state check, and close() frees before
NULLing. That is exactly the cross-thread teardown that corrupted the heap in
PortAudio's ALSA backend before v0.6.2.

The abort now happens under the lock the TX thread must hold to tear down.
The module's own stress testing puts abort() well under a millisecond, so
holding it is cheap.

Tests

Two regression tests, both verified to fail without their fix. The swap test
detaches _request_rx_reset from the worker's slot first, so the only way
reset() can be reached is a direct call — otherwise the spy can't tell the
two apart.

137 passed across tests/ui/test_stability_fixes.py, test_rx_worker.py and
tests/audio; ruff clean.

Not addressed here

The review also flagged nested event loops letting closeEvent re-enter, and
_abort_offline_workers blocking up to 20 s then calling terminate() on a
thread likely inside numpy. Both are real, both are bigger than this PR, and
given the history in this file I'd rather they land on their own.

🤖 Generated with Claude Code