Thanks for the well-researched fix @jensenpat — the PR description and root-cause analysis are clear, and the overall approach (sequenced teardown with sendCommandAndWait, removing the self client disconnect, and adding the 0x04 marker) is sound.

A few things I'd like to discuss:

1. QEventLoop re-entrancy in sendCommandAndWait

The nested QEventLoop in sendCommandAndWait is invoked during disconnect teardown. Because loop.exec() pumps all events, other queued signals (status updates, further command responses, timer firings) will be delivered while we're waiting for the stream-remove ACK. This is generally safe here since heartbeat is already stopped and we're tearing down, but it's worth a comment noting this is intentional and safe only because we're in teardown state.

More concretely: if onSocketError fires during the loop (e.g., the radio drops TCP mid-teardown), the new code at line ~249 calls setState(Disconnected) which emits stateChanged — but the loop also connects m_socket::disconnected to quit. Is there a race where the loop could exit via the timer and the disconnect signal fires afterward, leaving dangling state? The disconnect() calls after loop.exec() should prevent double-delivery, but worth a quick sanity check.

2. writeDisconnectMarker() called unconditionally in disconnectFromRadio()

disconnectFromRadio() is now called from both gracefulDisconnect (after sequenced teardown) and from the destructor / other paths. The 0x04 marker is correct for self-disconnect, but is it safe to send during a forced disconnect where the radio already kicked us? If the socket is in an error state, write() will silently fail (which is fine), but the waitForBytesWritten(250) will block for 250ms unnecessarily. Consider guarding:

void RadioConnection::writeDisconnectMarker()
{
    if (!m_socket || m_socket->state() != QAbstractSocket::ConnectedState)
        return;
    // ...
}

Using ConnectedState instead of just checking != UnconnectedState avoids blocking on sockets in ClosingState or error states.

3. m_reconnectTimer retry on connection error

The new retry logic in onConnectionError starts m_reconnectTimer on a refused connection. The timer lambda calls m_connection->connectToRadio(m_lastInfo) — but connectToHost has an early return if m_state != Disconnected. After onSocketError sets Error state and then Disconnected (new code), this should work. Just confirming: is there a window where m_state is Error when the timer fires? If so, the reconnect would silently no-op. The new setState(Disconnected) after error on UnconnectedState should cover this, but it's a subtle ordering dependency.

4. forceDisconnect capture change — nice

The [conn = m_connection, handle] capture in forceDisconnect is a good fix — capturing this in a non-blocking lambda where the object might be destroyed is risky. Good catch.

5. Minor: m_reconnectTimer.stop() in onConnected

Correct addition — prevents a stale timer from firing after we've already reconnected successfully.

Overall this is a solid fix with good diagnostics logging. The sequenced approach matches how FlexLib handles teardown. The main actionable item is #2 (tightening the guard in writeDisconnectMarker to avoid a needless 250ms block on error-state sockets). The rest are observations for your consideration.

Nice work, and thanks for tracking down the client disconnect self-rejection behavior.