Desktop client fails to re-establish dropped relay socket; "Reconnect" ineffective, only full relaunch recovers

The macOS Desktop client intermittently shows "can't connect to relay – click to reconnect" and gets stuck: clicking Reconnect repeatedly does nothing, and only quitting and relaunching the app restores the connection.

### Symptoms
- Happens several times over the last few days, each occurrence lasting until a manual relaunch.
- The in-app **Reconnect** control does not recover the session — clicking it repeatedly has no effect.
- Full quit-and-relaunch immediately re-establishes the connection.

### Evidence the relay was up the whole time
- An independent external probe (DNS + TCP:443 + HTTPS GET) against the relay host ran every 60s across the same three-day period and logged **HTTP 200 with zero failures**, including the exact windows the client reported "can't connect".
- Network path was clean during a captured incident: WAN ~15 ms / 0% loss, LAN ~0.7 ms / 0% loss.

So on each occurrence the relay was reachable and healthy; the failure is on the client side (a WebSocket that has dropped and cannot be revived by the Reconnect action).

### Impact
The app goes silent (no messages in or out) until the user notices and manually relaunches. For always-on / agent use this means missed messages during the stuck window.

### Expected
Reconnect should re-establish the WebSocket, or the client should auto-recover a dropped socket without requiring a full restart.

### Environment
- macOS Desktop app
- Single self-hosted Buzz relay
- Intermittent; no reliable trigger identified yet

No source file, test, or entry point is named. Start by tracing the macOS Desktop app's Reconnect control and WebSocket lifecycle, then reproduce the dropped-relay condition and verify that Reconnect or automatic recovery restores messaging without a full relaunch.

Written by the indexing model from the issue text.