…hersdr#1361) (aethersdr#1376)

Add three recovery mechanisms for when Windows WASAPI audio sessions go
stale after idle/screensaver, which Qt's QAudioSink doesn't detect:

1. QMediaDevices::audioOutputsChanged listener — restarts the RX stream
   when USB audio devices (like Connect6) power-cycle or re-enumerate.

2. Zombie sink watchdog in the RX pacing timer — detects when bytesFree()
   is stuck at 0 for ~2 seconds while data is waiting, indicating a stale
   WASAPI handle, and forces a restart.

3. IdleState handling in stateChanged — catches the case where the sink
   transitions to Idle (not Stopped) with pending data, which the
   existing aethersdr#1303 recovery missed.

Co-authored-by: AetherClaude <aetherclaude@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

…1405)

The IdleState handler added in #1376 for stale WASAPI session recovery
was triggering a continuous stop/start loop during normal playback on
Windows. In Qt6 push-mode QAudioSink, IdleState fires whenever the
internal buffer drains between write ticks — this is normal behavior,
not an error. The handler misidentified it as a stale session and
restarted the sink, preventing audio from ever playing.

The existing zombie sink watchdog (bytesFree() stuck at 0 for ~2s)
already covers the original #1361 idle/screensaver recovery scenario.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…1405)

The IdleState handler added in #1376 for stale WASAPI session recovery
was triggering a continuous stop/start loop during normal playback on
Windows. In Qt6 push-mode QAudioSink, IdleState fires whenever the
internal buffer drains between write ticks — this is normal behavior,
not an error. The handler misidentified it as a stale session and
restarted the sink, preventing audio from ever playing.

The existing zombie sink watchdog (bytesFree() stuck at 0 for ~2s)
already covers the original #1361 idle/screensaver recovery scenario.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

…1405) (#1419)

The IdleState handler added in #1376 for stale WASAPI session recovery
was triggering a continuous stop/start loop during normal playback on
Windows. In Qt6 push-mode QAudioSink, IdleState fires whenever the
internal buffer drains between write ticks — this is normal behavior,
not an error. The handler misidentified it as a stale session and
restarted the sink, preventing audio from ever playing.

The existing zombie sink watchdog (bytesFree() stuck at 0 for ~2s)
already covers the original #1361 idle/screensaver recovery scenario.

Co-authored-by: AetherClaude <aetherclaude@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>