…t pattern

PR aethersdr#2026 added an `if (m_radeActive)` guard to VfoWidget's unconditional
`emit radeActivated(false, ...)` to prevent spurious deactivation of RADE
on a different slice when any slice changes mode. RxApplet had the identical
pattern but was not updated in the same PR.

Add `m_radeActive{false}` and `setRadeActive(bool)` to RxApplet (mirroring
VfoWidget and PhoneCwApplet), guard the false emit, and wire the setter in
MainWindow::activateRADE / deactivateRADE so the state tracks correctly.

The MainWindow `sliceId == m_radeSliceId` handler guard remains load-bearing
and prevents any behavioral regression; this is a defense-in-depth cleanup
for code clarity and future-proofing.

Closes aethersdr#2062

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

…2376)

* fix(rx-applet): add matching radeActivated guard to mirror VfoWidget

Closes #2062

PR #2026 patched VfoWidget so its mode-switch lambda only emits
`radeActivated(false, ...)` when RADE was actually active on that
widget. The MainWindow handler `(else if (sliceId == m_radeSliceId)
deactivateRADE())` makes the matching unguarded emit at
`RxApplet.cpp:396` harmless today, but the asymmetry is exactly the
shape of the multi-pan regression #2026 fixed: it would re-tear-down
RADE on a different slice if the MainWindow guard ever softened.

This applies the same defense-in-depth guard:

- Add `bool m_radeActive{false};` to `RxApplet.h` (private), mirroring
  `VfoWidget`.
- In the mode-combo lambda, set `m_radeActive = true` after emitting
  the activate signal.
- Wrap the deactivate emit in `if (m_radeActive) { ... m_radeActive =
  false; }` so a USB->LSB swap on a non-RADE slice no longer fires a
  spurious `radeActivated(false)`.

Comment cites #2026 inline so future readers see the parallel.
No behavior change in the steady state: MainWindow still owns the
authoritative `m_radeSliceId` check; this just stops shouting `false`
from a slice that never said `true`.

* fix(rx-applet): use slice mode pre-change instead of local m_radeActive flag

The local-flag pattern from VfoWidget doesn't transfer cleanly to
RxApplet because the lifecycle is different:

- VfoWidget is one instance per slice; m_radeActive is set externally
  by MainWindow::setRadeActive() so it tracks the authoritative state.
- RxApplet is a single instance rebound across slices via setSlice();
  the local flag isn't synced from MainWindow and isn't reset on
  setSlice(), so it gets out of sync in two real scenarios:

    1. Externally activated RADE (VfoWidget combo, profile load on
       startup, MainWindow::activateRADE direct path) leaves
       m_radeActive=false in RxApplet; subsequent mode change in
       RxApplet would suppress the deactivate emit and orphan the
       RADE engine.

    2. Slice 0 in RADE → slice switch to slice 1 (USB) doesn't reset
       the flag → user picks LSB on slice 1 → flag clears (because
       the lambda runs even when MainWindow's authoritative guard
       silently filters the spurious emit) → user switches back to
       slice 0 (still RADE) → guard now incorrectly suppresses.

Both reachable in normal multi-pan workflows, same class of bug as
docs/multi-pan-pitfalls.md catalogues.

The simpler fix uses what's already authoritative: the slice's
pre-change mode.  m_slice->setMode(mode) runs at the END of the
lambda, so m_slice->mode() inside the lambda still holds the prior
mode.  Read it directly; emit deactivate only when the slice was
actually in RADE.  No new state, no sync hazard, correct across:

  - single-instance setSlice() rebind
  - externally activated RADE
  - the multi-pan case the original PR was targeting

Co-Authored-By: Matt Van Horn <mvanhorn@nibbcorp.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Jeremy Fielder <kk7gwy@aethersdr.com>
Co-authored-by: Matt Van Horn <mvanhorn@nibbcorp.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Closes #2734

## Why

`RxApplet.cpp` was patched in #2376 so its mode-combo lambda only emits
`radeActivated(false, ...)` when `m_slice->mode() == "RADE"`. That guard
is never true in steady state.

"RADE" is a client-side-only concept. When the user selects RADE,
`setMode("RADE")` sends `slice set N mode=RADE` to the radio, which
ignores the unknown mode string and echoes back the real mode (`DIGL`
for 40m, `DIGU` for 60m/WSPR). `SliceModel::handleSliceStatus`
immediately overwrites `m_mode` from that echo. By the time the user
switches away from RADE, `m_slice->mode()` is already `"DIGL"` — the
guard always evaluates false, `radeActivated(false)` is never emitted,
`deactivateRADE()` never runs, and `audio_mute=1` is stranded on the
slice.

The radio's per-band stack saves that muted state. Returning to the band
(via the band-stack, on reconnect, or after a restart) reloads
`audio_mute=1`, making RX audio silently dead on that band until
manually toggled. All other bands are unaffected because they were saved
before RADE muted the slice.

## What changes

**`src/gui/RxApplet.cpp`** — remove the `mode() == "RADE"` guard; emit
`radeActivated(false, ...)` unconditionally, matching pre-#2376
behavior:

```cpp
// "RADE" is client-side only — the radio echoes back the real mode
// (DIGL/DIGU) immediately, so mode() == "RADE" is never true in
// steady state. Emit unconditionally; MainWindow's
// sliceId == m_radeSliceId check is the authoritative filter that
// prevents spurious deactivations from non-RADE slices (#2026).
emit radeActivated(false, m_slice ? m_slice->sliceId() : -1);
```

Net diff: +6 / −14 in one file.

## Why the unconditional emit is safe

`MainWindow`'s `radeActivated` handler (wired in `MainWindow.cpp`)
already guards:
```cpp
else if (sliceId == m_radeSliceId) deactivateRADE();
```
A spurious `radeActivated(false, sliceId)` from a non-RADE slice is
silently dropped there. That check is the safety #2026 actually relied
on for the multi-pan case — not the mode string.

`RxApplet` is also architecturally different from `VfoWidget`: a single
`RxApplet` instance cycles through whichever slice the user selects via
the tab row (N:1), whereas each `VfoWidget` is permanently bound to one
slice (1:1). A mode-string or boolean flag check in `RxApplet` is
inherently unreliable across slice rebinds; `MainWindow::m_radeSliceId`
is the right authority.

## Behavior

- **Steady state / multi-pan**: identical to today. A USB→LSB swap on a
non-RADE slice fires `radeActivated(false, sliceB)`; MainWindow drops it
because `sliceB != m_radeSliceId`. RADE on slice A is unaffected.
- **The fixed case**: user enables RADE on 40m, then switches to USB via
the RxApplet combo. `radeActivated(false, 0)` now fires; MainWindow
calls `deactivateRADE()`; `audio_mute` is restored; band-stack saves the
clean state.

## Verification

Tested on **FLEX-8400, firmware v4.1.5.39794**:
- Enable RADE on 40m via RxApplet combo → switch to USB → slice unmutes,
RADE engine stops ✓
- Enable RADE on 40m via VfoWidget combo → switch to USB via RxApplet
combo → same result ✓
- Multi-pan: RADE on slice 0 (Pan A), swap slice 1 (Pan B) USB→LSB via
RxApplet → RADE on Pan A remains active ✓
- Close + reopen AetherSDR, tune to 40m → audio present ✓

## Follow-on

A separate PR will add a `modeChanged` listener in
`MainWindow::activateRADE` to auto-deactivate RADE when the slice mode
changes via external paths (TCI client, profile load, remote SmartSDR
client). That closes the same class of bug regardless of which code path
drives the mode change.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>