…ile-switch recreate, debounced teardown (#3363, #3364, #3476) (#3496)

## Summary

Closes #3363
Closes #3476

Hotfix bundle for the TCI/WSJT-X RX-audio-loss cluster (#3363, #3476,
and the already-closed duplicate #3364; materially helps #2886 and
#3366), plus the diagnostics that root-caused it. All failures share one
shape: a DAX RX stream that WSJT-X depends on is torn down (or never
recreated) by a path that doesn't know WSJT-X still needs it. Structural
refcounting is tracked in #3305; these are the contained fixes users
need now.

Root-caused with hardware in the loop (FLEX + PGXL + TGXL +
WSJT-X-Improved console capture). Full investigation notes are on #3305
(two comments, 2026-06-08).

## Fixes

### 1. `stopDax()` ownership guard (#3363, helps #2886)
`MainWindow::stopDax()` unconditionally `stream remove`d every
registered DAX RX stream, so toggling the DAX bridge (or slice mute) off
ripped out the stream TCI had borrowed — silencing WSJT-X RX instantly
(confirmed in #3363's support bundle: stream `0x04000009` removed at
14:38:19, ~50 s blackout until WSJT-X retried). The sibling teardown
paths (RADE at ~17520, per-slice de-assign from #3308) already guard via
`TciServer::ownsDaxChannel()` / `m_radeDaxStreamId`; `stopDax()` was the
one that didn't. Now iterates channels 1–4 and keeps any stream another
consumer still holds.

### 2. Liveness-keyed recreation after profile switch (#3476, #3364)
`profile global load` destroys/recreates slices **without** a radio
disconnect. The reactive "radio removed DAX stream" handler zeroed the
cached stream id but **kept the channel key**, so `ensureDaxForTci()`'s
`contains(ch)` guard skipped `stream create` on the re-arm — TCI RX
stayed silent until a full reconnect ("switched profile, never came
back"; only Reset Settings recovered). The handler now **erases** the
entry (and its borrowed flag), so the next re-arm recreates. Pending
creates (value 0) are never matched (`streamId != 0`), so in-flight
requests are safe.

### 3. Debounced DAX RX teardown (Tune/ATU + transient reconnects)
Field-reproduced: a band change landing during a TGXL ATU tune stalls
the main loop ~2 s → the `vfo:` echo misses WSJT-X's hard 2000 ms
`do_frequency` timeout → WSJT-X throws `TCI failed set rxfreq`, **closes
the socket**, and reconnects ~2–3.5 s later.
`onClientDisconnected`/`audio_stop` previously called
`releaseDaxForTci()` immediately, turning that blip into permanent
silence.

Now the teardown is deferred by `kDaxReleaseGraceMs` (10 s — measured
drop→`audio_start` gaps were 2.1/3.3/3.5 s); a (re)connecting client's
`audio_start` cancels it, so the stream survives and audio resumes with
no recreate. `stop()` still tears down immediately. Also clears
`m_tciDaxSlices` on radio disconnect so a deferred release after a quick
radio bounce can't `setDaxChannel(0)` on recreated slices.

The underlying ~2 s stall is **not** fixed here — it's the remaining
root bug, and the watchdog below is aimed at it.

## Diagnostics (kept deliberately)

- **Outbound TCI traffic logging** — `TCI tx→all:` / `tx→client:` /
`tx→init:` (`qCDebug(lcCat)`). We logged every inbound command but
nothing we sent; the `vfo:` echo WSJT-X times out on was invisible. This
is what made the Tune/ATU root cause provable.
- **Teardown logs elevated to `qCWarning`** — `releaseDaxForTci()`,
client TCP drop, `audio_stop`. These ran **completely invisibly** in the
26.6.2 field bundles because `qCInfo(lcCat)` sits below the default
warning threshold even with `aether.cat.debug` enabled. An audio-killing
teardown should never be silent.
- **Main-thread stall watchdog** (`main.cpp`) — 250 ms heartbeat; logs
`MainThreadWatchdog: event loop stalled ~N ms` (warning) for any
GUI-loop block > 600 ms. Stall start ≈ timestamp − gap. Converts the
next field stall into a single timestamped line.

## Validation

- Built clean on macOS (RelWithDebInfo, Ninja), rebased onto current
`main` and rebuilt.
- Live rig (FLEX + PGXL + TGXL + WSJT-X-Improved): 4 consecutive
`profile global load` switches with TCI audio flowing — `frames_sent`
climbed monotonically across all of them, zero teardowns; on client
quit, the debounce deferred 10 s and released cleanly (`0 stream(s), 0
slice assignment(s)`).
- Watchdog verified live (caught a benign ~1.1 s startup stall; silent
during all profile switches — confirming the 2 s stall is specific to
the Tune/ATU path).
- WSJT-X console + AetherSDR log correlation for the Tune/ATU repro:
throw at 05:05:40.715, our delayed `vfo:` processing at 05:05:40.726 —
2.0 s after WSJT-X sent it.

## Out of scope / follow-ups

- The ~2 s band-change+ATU main-thread stall (root cause of the WSJT-X
throws) — to be filed separately; the watchdog pinpoints it on next
occurrence.
- WSJT-X waterfall blanking for ~5 s when a profile load retunes the
radio to a band the client didn't request (cosmetic; client-side
reconciliation) — policy question, separate issue.
- Centralized DAX RX refcounting — #3305 (design requirements documented
there).

💻 Generated with Claude Code (Fable 5.0) with architecture by @jensenpat

---------

Co-authored-by: Codex <noreply@openai.com>

…ethersdr#2895) (aethersdr#3308)

Fixes aethersdr#2895

## Problem
`MainWindow::startDax()` only sent `stream create type=dax_rx
dax_channel=N` once at bridge startup, iterating slices that *already*
had a DAX channel — in practice just slice 0 / DAX 1. When the user
later assigned DAX 2–4 to another slice via the UI,
`SliceModel::setDaxChannel()` only sends `slice set <id> dax=<ch>` and
never `stream create`, so the radio never registers a DAX client
(`dax_clients` stays 0) and sends silence. Slices 1–3 were mute on Linux
PipeWire (the report) and macOS. The reporter confirmed slices 1–3 DAX
assignments aren't persisted, so the "assign-all-then-toggle" workaround
can't work — a code fix was the only path.

## Fix
React to per-slice `daxChannelChanged` (and `RadioModel::sliceAdded`)
while the bridge is up, mirroring the proven TCI path
(`TciServer::ensureDaxForTci`, aethersdr#1331/aethersdr#1439) and FlexLib
`RequestDAXRXAudioStream(channel)`:
- **0 → 1..4**: create the stream if `daxStreamIdForChannel(newCh) ==
0`, then re-assert `slice set <id> dax=<newCh>` (the aethersdr#1439
client-registration workaround). The status echo registers the stream in
`PanadapterStream`.
- **release / move**: remove the old channel's stream when no other
slice references it.
- `stopDax()` drops the new connections so late signals can't hit a
torn-down bridge.

### Cross-consumer ownership guard
The `PanadapterStream` DAX map is shared across the bridge, TCI (which
*borrows* bridge-created streams) and RADE. The removal path now
consults `TciServer::ownsDaxChannel()` and `m_radeDaxStreamId`, so
de-assigning a slice's DAX channel never tears out a stream WSJT-X or
RADE is still using — the mirror image of aethersdr#3270. Full consolidation of
this hand-rolled coordination is tracked in aethersdr#3305.

## Files
- `src/gui/MainWindow.cpp` / `.h` — `startDax()`/`stopDax()`, new
`wireDaxSlice()` / `onDaxChannelChanged()`, `m_daxSliceConns` /
`m_daxSliceLastCh`
- `src/core/TciServer.h` — new `ownsDaxChannel(int)` accessor

## Testing
Builds clean (macOS). Manual:
1. 2 slices (A on DAX 1, B on none); enable DAX bridge → A audio flows,
`dax_clients=1` on ch 1.
2. Assign DAX 2 to slice B via UI → expect `stream create dax_channel=2`
+ `slice set B dax=2`, `dax_clients=1` on ch 2, audio on the
previously-idle sink.
3. Re-assign B back to none → `stream remove` sent, ch 2 quiet, others
keep flowing.
4. **Ownership guard:** with WSJT-X decoding on a DAX channel over TCI
*and* the bridge up, de-assign that channel from the slice → WSJT-X
audio keeps flowing; log shows `keeping DAX RX stream … still used by
TCI`.

💻 Generated with Claude Code (Opus 4.8) with architecture by @jensenpat

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Codex <noreply@openai.com>

…ile-switch recreate, debounced teardown (aethersdr#3363, aethersdr#3364, aethersdr#3476) (aethersdr#3496)

## Summary

Closes aethersdr#3363
Closes aethersdr#3476

Hotfix bundle for the TCI/WSJT-X RX-audio-loss cluster (aethersdr#3363, aethersdr#3476,
and the already-closed duplicate aethersdr#3364; materially helps aethersdr#2886 and
aethersdr#3366), plus the diagnostics that root-caused it. All failures share one
shape: a DAX RX stream that WSJT-X depends on is torn down (or never
recreated) by a path that doesn't know WSJT-X still needs it. Structural
refcounting is tracked in aethersdr#3305; these are the contained fixes users
need now.

Root-caused with hardware in the loop (FLEX + PGXL + TGXL +
WSJT-X-Improved console capture). Full investigation notes are on aethersdr#3305
(two comments, 2026-06-08).

## Fixes

### 1. `stopDax()` ownership guard (aethersdr#3363, helps aethersdr#2886)
`MainWindow::stopDax()` unconditionally `stream remove`d every
registered DAX RX stream, so toggling the DAX bridge (or slice mute) off
ripped out the stream TCI had borrowed — silencing WSJT-X RX instantly
(confirmed in aethersdr#3363's support bundle: stream `0x04000009` removed at
14:38:19, ~50 s blackout until WSJT-X retried). The sibling teardown
paths (RADE at ~17520, per-slice de-assign from aethersdr#3308) already guard via
`TciServer::ownsDaxChannel()` / `m_radeDaxStreamId`; `stopDax()` was the
one that didn't. Now iterates channels 1–4 and keeps any stream another
consumer still holds.

### 2. Liveness-keyed recreation after profile switch (aethersdr#3476, aethersdr#3364)
`profile global load` destroys/recreates slices **without** a radio
disconnect. The reactive "radio removed DAX stream" handler zeroed the
cached stream id but **kept the channel key**, so `ensureDaxForTci()`'s
`contains(ch)` guard skipped `stream create` on the re-arm — TCI RX
stayed silent until a full reconnect ("switched profile, never came
back"; only Reset Settings recovered). The handler now **erases** the
entry (and its borrowed flag), so the next re-arm recreates. Pending
creates (value 0) are never matched (`streamId != 0`), so in-flight
requests are safe.

### 3. Debounced DAX RX teardown (Tune/ATU + transient reconnects)
Field-reproduced: a band change landing during a TGXL ATU tune stalls
the main loop ~2 s → the `vfo:` echo misses WSJT-X's hard 2000 ms
`do_frequency` timeout → WSJT-X throws `TCI failed set rxfreq`, **closes
the socket**, and reconnects ~2–3.5 s later.
`onClientDisconnected`/`audio_stop` previously called
`releaseDaxForTci()` immediately, turning that blip into permanent
silence.

Now the teardown is deferred by `kDaxReleaseGraceMs` (10 s — measured
drop→`audio_start` gaps were 2.1/3.3/3.5 s); a (re)connecting client's
`audio_start` cancels it, so the stream survives and audio resumes with
no recreate. `stop()` still tears down immediately. Also clears
`m_tciDaxSlices` on radio disconnect so a deferred release after a quick
radio bounce can't `setDaxChannel(0)` on recreated slices.

The underlying ~2 s stall is **not** fixed here — it's the remaining
root bug, and the watchdog below is aimed at it.

## Diagnostics (kept deliberately)

- **Outbound TCI traffic logging** — `TCI tx→all:` / `tx→client:` /
`tx→init:` (`qCDebug(lcCat)`). We logged every inbound command but
nothing we sent; the `vfo:` echo WSJT-X times out on was invisible. This
is what made the Tune/ATU root cause provable.
- **Teardown logs elevated to `qCWarning`** — `releaseDaxForTci()`,
client TCP drop, `audio_stop`. These ran **completely invisibly** in the
26.6.2 field bundles because `qCInfo(lcCat)` sits below the default
warning threshold even with `aether.cat.debug` enabled. An audio-killing
teardown should never be silent.
- **Main-thread stall watchdog** (`main.cpp`) — 250 ms heartbeat; logs
`MainThreadWatchdog: event loop stalled ~N ms` (warning) for any
GUI-loop block > 600 ms. Stall start ≈ timestamp − gap. Converts the
next field stall into a single timestamped line.

## Validation

- Built clean on macOS (RelWithDebInfo, Ninja), rebased onto current
`main` and rebuilt.
- Live rig (FLEX + PGXL + TGXL + WSJT-X-Improved): 4 consecutive
`profile global load` switches with TCI audio flowing — `frames_sent`
climbed monotonically across all of them, zero teardowns; on client
quit, the debounce deferred 10 s and released cleanly (`0 stream(s), 0
slice assignment(s)`).
- Watchdog verified live (caught a benign ~1.1 s startup stall; silent
during all profile switches — confirming the 2 s stall is specific to
the Tune/ATU path).
- WSJT-X console + AetherSDR log correlation for the Tune/ATU repro:
throw at 05:05:40.715, our delayed `vfo:` processing at 05:05:40.726 —
2.0 s after WSJT-X sent it.

## Out of scope / follow-ups

- The ~2 s band-change+ATU main-thread stall (root cause of the WSJT-X
throws) — to be filed separately; the watchdog pinpoints it on next
occurrence.
- WSJT-X waterfall blanking for ~5 s when a profile load retunes the
radio to a band the client didn't request (cosmetic; client-side
reconciliation) — policy question, separate issue.
- Centralized DAX RX refcounting — aethersdr#3305 (design requirements documented
there).

💻 Generated with Claude Code (Fable 5.0) with architecture by @jensenpat

---------

Co-authored-by: Codex <noreply@openai.com>