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:

// 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