…hersdr#2968)

## Problem

When the user exits AetherSDR with RADE mode active (File → Exit or the
window close button), the slice that was RADE-assigned ends up **muted
on the next session** even though RADE is not running.

---

### Root cause 1 — sequencing error in `closeEvent()`

`activateRADE()` mutes the slice (`slice set N audio_mute=1`) and saves
the pre-RADE mute state in `m_radePrevMute`. `deactivateRADE()` restores
it.

The problem: `closeEvent()` calls `disconnectFromRadio()` to close the
TCP socket, and _then_ the destructor calls `deactivateRADE()`. By the
time `deactivateRADE()` tries to send the restore command (`slice set N
audio_mute=0`), the socket is already closed. The command is silently
dropped.

```
closeEvent() — original broken order:
  1. preparePanadapterUiForShutdown()
  2. s.save()
  3. m_radioModel.disconnectFromRadio()   ← socket closed HERE
  ...
~MainWindow() — too late:
  4. if (m_radeSliceId >= 0) deactivateRADE()  ← audio_mute=0 dropped
```

**Fix:** Call `deactivateRADE()` in `closeEvent()` before
`disconnectFromRadio()`, inside an `#ifdef HAVE_RADE` guard. The
destructor guard is unchanged — it is already idempotent because
`deactivateRADE()` sets `m_radeSliceId = -1`.

---

### Root cause 2 — `WanConnection::sendCommand()` missing `flush()`

Testing on a WAN (SmartLink) connection showed the fix from RC1 was not
effective: `audio_mute=1` still persisted after exit. Diagnostic logging
confirmed `deactivateRADE()` was being reached correctly
(`connected=true`, correct slice ID and prev-mute value). The failure
was one layer deeper, in `WanConnection::sendCommand()`:

```cpp
// Before — data placed in SSL plaintext buffer but never pushed to OS:
m_socket.write(data);
return seq;

// After — matches RadioConnection::writeCommand() behaviour:
m_socket.write(data);
m_socket.flush();   // push SSL plaintext buffer to OS TCP buffer immediately
return seq;
```

`QSslSocket::write()` queues data in Qt's SSL plaintext buffer. Without
`flush()`, the SSL layer never encrypts and sends those bytes until the
Qt event loop runs. Since `closeEvent()` calls `disconnectFromRadio()`
immediately after `deactivateRADE()` without yielding to the event loop,
the `audio_mute=0` bytes were sitting in the SSL buffer when the socket
closed.

`flush()` forces the SSL layer to encrypt and push the bytes to the OS
kernel TCP buffer synchronously — TCP then guarantees their delivery
before the FIN. The LAN path (`RadioConnection::writeCommand()`) already
called `flush()` for exactly this reason; the WAN path was simply
missing it.

Note: on a direct LAN connection the RC1 fix alone would have been
sufficient — the LAN command path dispatches via
`QMetaObject::invokeMethod` to a dedicated connection thread that
explicitly flushes, so the timing is structurally different.

---

## Files changed

| File | Change |
|---|---|
| `src/gui/MainWindow.cpp` | Call `deactivateRADE()` in `closeEvent()`
before `disconnectFromRadio()` |
| `src/core/WanConnection.cpp` | Add `m_socket.flush()` after `write()`
in `sendCommand()` |

## Test plan

- [x] **WAN (SmartLink)**: Enable RADE, exit via File → Exit, reconnect
— slice unmuted ✓
- [ ] **LAN (direct)**: Same test on a direct local connection
- [x] Exit via title-bar X button — slice unmuted on reconnect
- [x] Exit without RADE active — no crash, no behaviour change
- [x] Enable RADE, manually deactivate via mode selector, then exit —
mute state correct on reconnect
- [x] Log shows `"MainWindow: RADE mode deactivated"` exactly once per
session (destructor guard is no-op on normal close path)

Principle XIV.

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

---------

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