Windows Desktop: cannot-connect-to-relay state does not self-recover; full relaunch required

## Summary

Cross-platform confirmation of the recovery class in #3975: on Windows, Buzz Desktop intermittently enters a `cannot connect to relay` state and does not recover on its own. The operator has had to fully quit/relaunch Buzz Desktop multiple times to restore service.

This is a connection-failure report, separate from API/event silent-success bugs.

## Environment

- OS: Windows
- Relay: Block-hosted private community relay
- Observed repeatedly through 2026-08-05
- Exact Desktop build: unknown. The bundled `buzz` CLI does not support `--version`, and the local executable has no populated PE file/product version metadata.

## Operator-observed behavior

1. Desktop displays `cannot connect to relay`.
2. The state persists rather than reconnecting automatically.
3. A full Buzz Desktop restart restores the connection.
4. This has occurred multiple times, not as a one-off startup failure.

No deterministic trigger is known yet.

## Local evidence and boundary

I searched the app’s Roaming and Local data directories for `.log`, `.txt`, `.json`, and `.jsonl` files containing connection/reconnect terms. The install exposes managed-agent harness logs, but I found no Desktop UI/runtime connection log that records the reported `cannot connect` banner, retry decisions, or successful/failed Desktop socket replacement.

The agent harness logs do corroborate transport instability on the same machine, but **do not prove the Desktop UI’s stuck state**. Example sanitized sequence from 2026-08-04 UTC:

```text
16:30:21 WebSocket background task: fatal TLS alert BadRecordMac
16:30:21 relay event stream ended; reconnect requested
16:30:29 reconnect attempt 1 failed: Connection closed
16:30:36 reconnect attempt 2 failed: Connection closed
16:30:45 reconnect attempt 3 succeeded; resubscribed
```

Other local agent logs contain HTTP 503, DNS resolution failures, and reconnect ladders. Those logs show the underlying connection can flap and that the ACP path sometimes recovers. They do not explain why the Desktop client sometimes remains stuck until relaunch.

Because no Desktop connection log is available, the root cause here is intentionally left unproven.

## Expected behavior

- Desktop automatically replaces a failed WebSocket and resubscribes after the relay/path recovers.
- If automatic recovery exhausts a bounded ladder, the UI retry action starts a fresh connection state machine.
- A full application relaunch is not required.
- Diagnostic logs identify socket close/error, retry attempt/result, auth result, subscription restoration, and terminal failure reason.

## Impact

The client can remain silently offline until a human notices the banner and restarts the app. Messages and managed-agent coordination are missed during that window.

## Suggested next steps

1. Add durable Desktop connection-state logs and a copy-diagnostics action.
2. Ensure reconnect creates a new socket/client state rather than reusing a terminally failed instance.
3. Add jittered indefinite background retries after the fast bounded ladder.
4. On reconnect, perform subscription catch-up from a persisted cursor before declaring the client online.
5. Add a Windows integration test that drops the relay connection, restores it, and verifies timeline/subscription recovery without relaunch.

Related: #3975 reports the same full-relaunch recovery requirement on macOS/self-hosted relay. This report adds repeated Windows + hosted-relay observations, while noting that Desktop diagnostic logs were unavailable. #4743 covers a separate hosted-relay fan-out / silently dead-subscription class.

Start by locating the Windows Desktop connection-state and WebSocket reconnect entry points, then review how failed sockets, retry attempts, authentication, and subscription restoration are handled. Use the suggested Windows integration test scenario—drop the relay connection, restore it, and verify recovery without relaunch—as the completion check, including diagnostic evidence for terminal failure.

Written by the indexing model from the issue text.