fix(mobile): detect half-open relay sockets with client-side ping/pong

[Dirtywater97]

Fixes gap 1 of #3224 — the one behind the reported symptom.

Problem

The relay pings every 30s and closes after 3 missed pongs (crates/buzz-relay/src/connection.rs:378-400). That protects the relay from dead clients; it does nothing for the client.

Mobile networks — cellular especially — silently drop idle TCP flows without sending a FIN. When that happens the phone's WebSocket never receives a close frame, so neither onError nor onDone fires in relay_socket.dart:84-96, RelaySessionNotifier is never told to reconnect, and the socket stays dead while the UI reports connected. A Play Store user described the result as "constantly having to force quit the app just to see a message."

Fix

WebSocketChannel.connect resolves to AdapterWebSocketChannel, which exposes no ping configuration (web_socket_channel/lib/src/channel.dart:107-108). IOWebSocketChannel does — and the package is already a direct dependency (mobile/pubspec.yaml:20, locked at 3.0.3):

If a ping message is not answered by a pong message from the peer, the WebSocket is assumed disconnected and the connection is closed with a goingAway close code.

So the missing liveness detection is a constructor away. The unanswered ping produces a normal close, which reaches the existing onDone handler and drives the existing reconnect path — no new lifecycle handling.

mobile/ has android/ and ios/ and no web target, so binding to the dart:io implementation is safe. The connector is isolated in relay_websocket_connector.dart so relay_socket.dart changes by one call site plus an import.

On the interval

dart:io never has two pings outstanding: it waits one interval, sends a ping, then allows one more for the pong. Detection therefore takes up to 2 × interval — ~40s at 20s, keeping foreground recovery under a minute. Cost is three extra ping/pong exchanges per idle foreground minute; the session already disconnects 5s after backgrounding (relay_session.dart:316-329), so this doesn't run while suspended. 30s would halve the traffic and roughly double time-to-detection — happy to change it if you prefer that trade.

Alternative you may prefer

Desktop solved this with a passive watchdog (relayStallWatchdog.ts) that treats inbound traffic as the liveness signal, chosen deliberately for a Tauri constraint documented at the top of that file. That constraint doesn't apply to Flutter, and active ping/pong is far less code here. But if you'd rather keep the two clients symmetric, say so and I'll port the watchdog shape instead.

Testing

New test stands up a raw ServerSocket that completes the WebSocket handshake and then goes silent — never answering pings, never sending a close frame. A dart:io WebSocket server can't express this because it auto-replies to pings, hence the manual handshake.

It asserts the socket closes cleanly through onDone with close code 1001, not via onError — the distinction that matters, since only a clean close exercises the reconnect path.

Verified in both directions:

• Against WebSocketChannel.connect: fails — socket stays open indefinitely.
• With ping/pong enabled: passes in ~400ms at a 200ms test interval.

dart format --output=none --set-exit-if-changed .   0 changed
flutter analyze                                     No issues found!
flutter test                                        825 passed, 1 skipped

Baseline before this change was 823 passed, 1 skipped — the 2 new tests are the only delta, no regressions.

Not included

Gaps 2–5 from #3224 (8s vs 25s timeouts, missing backoff jitter, backoff resetting on connect rather than on stability, dropped NOTICE frames) are deliberately left out so this stays independently reviewable and revertable. Happy to follow up with those in a separate PR.