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>