Follow-on to #2745.

## Why
`activateRADE()` sets `audio_mute=1` on the RADE slice, expecting
`deactivateRADE()` to restore it when the user switches away from RADE.
The VfoWidget and RxApplet mode combos handle this for UI-driven mode
changes. But three paths bypass both combos entirely:

- **TCI client** sending `mode USB` (e.g. WSJT-X or a logging program
switching modes via CAT)
- **Profile load** that sets a non-DIGU/DIGL mode on startup or on
profile switch
- **Remote SmartSDR client** on the same radio changing the slice mode
from another machine

In all three cases, `modeChanged` fires on the `SliceModel` but neither
combo emits `radeActivated(false)`. `deactivateRADE()` never runs,
`audio_mute=1` is stranded on the slice, and the radio's band-stack
saves that muted state. The result is the same silent RX-audio loss as
#2734, triggered by a different path.

## What changes

**`src/gui/MainWindow.cpp` / `MainWindow.h`** — connect
`SliceModel::modeChanged` on the RADE slice when RADE activates;
deactivate automatically if the mode leaves the DIGU/DIGL family:

```cpp
// activateRADE() — after m_radeSliceId = sliceId
connect(s, &SliceModel::modeChanged,
        this, &MainWindow::onRadeSliceModeChanged,
        Qt::UniqueConnection);

// onRadeSliceModeChanged()
void MainWindow::onRadeSliceModeChanged(const QString& mode)
{
    if (mode != "DIGU" && mode != "DIGL")
        deactivateRADE();
}

// deactivateRADE() — before state teardown
disconnect(s, &SliceModel::modeChanged,
           this, &MainWindow::onRadeSliceModeChanged);
```

Net diff: +21 / −1 across two files.

## Design notes

**Why not guard against DIGU→DIGL transitions?** `activateRADE()` sets
the mode to `DIGL` or `DIGU` based on band convention. If the mode flips
between the two (e.g. a band change that crosses the 10 MHz boundary),
RADE deactivates cleanly and the user re-enables it. Keeping the
same-family pass-through would add complexity for a case where
re-activation is the right behavior anyway.

**Re-entrancy:** The disconnect in `deactivateRADE()` runs before
`m_radeSliceId` is cleared and before any further `setAudioMute` or
engine teardown. If `onRadeSliceModeChanged` somehow fires during
teardown, the signal is already disconnected at the point of re-entry.
`Qt::UniqueConnection` additionally prevents double-connection if
`activateRADE()` is called twice in quick succession (e.g. VfoWidget and
RxApplet both emitting `radeActivated(true)` simultaneously — the
duplicate-activation guard at the top of `activateRADE()` normally
prevents this, but `UniqueConnection` adds a second layer).

**`modeChanged` during initial `activateRADE()`:** `activateRADE()`
calls `s->setMode("DIGL"/"DIGU")` before connecting the signal, so the
radio-echo `modeChanged("DIGL")` that arrives later fires on a connected
slot — but the check `mode != "DIGU" && mode != "DIGL"` correctly passes
through, and no deactivation occurs.

## Verification

- Enable RADE on 40m → send `slice set 0 mode=USB` via TCI/CAT console →
RADE deactivates, slice unmutes ✓
- Enable RADE on 40m → load a profile with mode=USB → RADE deactivates
cleanly ✓
- Enable RADE on 40m → change frequency to a DIGU-default band → mode
echoes as DIGU → RADE stays active ✓
- Normal UI deactivation (VfoWidget / RxApplet combo) unaffected ✓
- Multi-pan: no spurious deactivations on mode changes to unrelated
slices ✓

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

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