Desktop 0.5.7 (Windows) cannot connect to a hosted relay, transport is fine

**Title:** Desktop 0.5.7 (Windows) never connects to a Block-hosted relay — every subscription fails with "Failed to connect to relay" while a raw WebSocket from the same origin opens fine

## Describe the bug

Buzz Desktop 0.5.7 on Windows shows a persistent "Can't reach the relay / Click to connect" banner against a Block-hosted community. Clicking the banner does nothing. The UI renders cached state (channels, members, the Fizz welcome thread) but no live traffic flows: no new messages arrive, and outgoing sends never leave the composer.

The relay itself is reachable and healthy from the same machine, and a raw WebSocket opened from the app's own WebView origin connects successfully. Only the app's internal relay client fails.

## Environment

- Buzz Desktop 0.5.7 (Windows x64, NSIS install at `%LOCALAPPDATA%\Buzz\buzz-desktop.exe`)
- Windows [FILL IN: e.g. 11 24H2]
- Block-hosted relay: `wss://"name-of-my-community".communities.buzz.xyz`
- Relay NIP-11 reports `version: 0.2.0`, `auth_required: true`, `restricted_writes: true`
- No VPN or proxy. No self-hosted relay involved.

## Steps to reproduce

1. Open Buzz Desktop against the hosted community.
2. Observe the sidebar banner "Can't reach the relay / Click to connect".
3. Click it. Nothing changes; the banner cycles between "Connecting / Reconnecting" and the failed state.

## What the app logs

The WebView console floods with the same error, once per channel, on a continuous retry loop. The error counter climbed from 588 to 841 in roughly five minutes of idle time:

```
Failed to subscribe to mention events Error: Failed to connect to relay.
at Object.normalizeRelayError (hooks-Bw9swr0W.js:2:21041)
at Object.connect (hooks-Bw9swr0W.js:2:20128)
at async Object.ensureConnected (hooks-Bw9swr0W.js:2:18898)

Failed to subscribe to membership notifications Error: Failed to connect to relay.
Failed to subscribe to live channel updates Error: Failed to connect to relay.
[community ThemeSync] publish failed: Error: Failed to connect to relay.
```

Process stderr contains nothing about the relay at all — only:

```
buzz-desktop: persisted identity pubkey
buzz-desktop: media proxy listening on 127.0.0.1:62644
buzz-desktop: repos dir resolved at boot — no configured override, REPOS is the default real dir
```

## What we ruled out

Each of these was tested, not assumed:

1. **Client version.** 0.5.7, current at time of writing. Not a stale build.
2. **Relay availability.** The NIP-11 document loads in a normal browser over HTTPS and returns valid JSON.
3. **Network path and Cloudflare.** A raw WebSocket from Chrome at the relay's own origin returns `OPEN`, then `CLOSE 1005` (expected: nothing signs the NIP-42 challenge). `curl` gets a Cloudflare 403 regardless of User-Agent, but that is TLS-fingerprint bot filtering and is not specific to this machine.
4. **CORS / WebView origin.** This was the strongest hypothesis, given issue #3490 about `http://tauri.localhost` missing from CORS guidance. It does not apply here. Running the following in the app's own DevTools console (origin `http://tauri.localhost`, via `--remote-debugging-port`) returns `OPEN`:

```js
const ws = new WebSocket("wss://"name-of-my-community".communities.buzz.xyz");
ws.onopen = () => console.log("OPEN");
ws.onerror = e => console.log("ERR", e);
ws.onclose = e => console.log("CLOSE", e.code, e.reason);
```

5. **Relay URL configuration.** Settings shows exactly `wss://"name-of-my-community".communities.buzz.xyz`, no trailing slash, correct scheme.
6. **Identity.** `identity.migrated` is present in `%APPDATA%\xyz.block.buzz.app`, and the persisted pubkey matches the one the community knows.

So: the transport works from the app's process, with the app's origin, to this relay. The failure is inside the client's own connect path.

## Possibly relevant

- The app **did** sync successfully at first. Local storage shows member count on the Welcome channel rising from 4 to 7, profiles for Fizz, Honey and Bumble resolving, and a DM channel being created, all within a few minutes of first launch. It then stopped and never recovered.
- Local storage contains the key `buzz-local-storage-quota-recovery.v1`, so the app has hit a localStorage quota limit at some point on this profile. Possibly unrelated, but it suggests local state may be in a recovered or partial condition.
- A draft ("hello") has been stuck in a DM with status `active` since the disconnect and has never been sent.
- This may be related to #4749 (hosted relay intermittently stalls desktop message loading and disconnects), though in our case the state is permanent rather than intermittent, and app restarts do not recover it.

## Expected behavior

The client establishes and holds the WebSocket, completes NIP-42 auth, and subscribes to channels. Failing that, the banner should surface the underlying reason (handshake status, close code, auth rejection) instead of a generic "Can't reach the relay", which sends users down the network-diagnostics path for hours when the network is fine.

## Additional data available on request

DevTools Network tab WS entry [FILL IN: paste the handshake status and close code here if you captured it], full console dump, managed-agent logs.