Desktop 0.5.5: fresh install adopts the local dev relay and hangs on "connecting to relay" with no error; BUZZ_RELAY_URL does not reach the UI

### Describe the bug

Setting up Buzz Desktop 0.5.5 on a second Mac, the app accepted my imported nsec and then hung indefinitely on "connecting to relay". No error was ever surfaced in the UI.

The cause was that the community record's `relayUrl` pointed at the **local dev relay** (`localhost:3000`) rather than my hosted community. That machine had the `buzz` repo checked out, which appears to be how the local dev URL got seeded into a normal (non-dev) install.

Two things made this take hours to diagnose:

**1. `BUZZ_RELAY_URL` does not feed the desktop UI.**

The UI reads its relay from the webview LocalStorage key `buzz-communities` (origin `tauri://localhost`). Setting `BUZZ_RELAY_URL` in the environment fixed the CLI and buzz-mesh but had no effect on the window — so the CLI answered instantly and correctly while the app spun forever. This actively masks the problem, because the obvious isolation test (run the CLI with the same env) passes.

Confirmed on a working machine: `ps eww` on the running `buzz-desktop` process (launched by double-click) shows **zero** `BUZZ_*` variables, and it connects fine. So the relay genuinely never comes from the environment for the UI.

**2. The only visible error came from an unrelated subsystem.**

Terminal output while the window hung:

```
buzz-mesh: installed tokio runtime with 8 MiB worker stacks
buzz-desktop: configured identity pubkey 3b53973f…
buzz-desktop: shared-agent-sync: skipping — data dir is not a dev dir
buzz-desktop: media proxy listening on 127.0.0.1:52116
buzz-desktop: repos dir resolved at boot — no configured override, REPOS is the default real dir
buzz-mesh: status report after workspace apply failed: relay unreachable: could not connect to relay
```

The only relay error names **buzz-mesh** (shared compute), not chat. The actual chat relay misconfiguration logged nothing at all, so the one error message present points at the wrong subsystem.

### Steps to reproduce

1. On a machine that has the `buzz` repo checked out, install Buzz Desktop 0.5.5 fresh
2. Import an existing identity (nsec) rather than accepting the generated key
3. Observe the app moves to "connecting to relay" and stays there

**Expected:** the app connects to the community, or tells me which relay URL it is failing to reach.

**Actual:** indefinite spinner, no relay URL shown, no error. `Settings → edit community` reveals the URL is the local dev relay.

### Isolation evidence

Running the bundled CLI on the same machine, at the same moment, returned all 8 channels including private DMs — proving network reachability, key validity, and relay membership were all fine:

```bash
export BUZZ_PRIVATE_KEY=nsec1…
export BUZZ_RELAY_URL=wss://.communities.buzz.xyz
/Applications/Buzz.app/Contents/MacOS/buzz channels list
# → full JSON channel list, instantly
```

### Workaround

`Settings → edit community →` replace the local dev URL with the real relay (`wss://.communities.buzz.xyz`). Reconnected **instantly, with no restart**.

### Suggested fixes

- Surface the relay URL and the underlying connection error in the connecting state, rather than an unlabeled spinner. A spinner that says which host it is dialing would have made this a 30-second diagnosis.
- Do not seed a local dev relay URL into a production install merely because a repo checkout is present on disk.
- If `BUZZ_RELAY_URL` is set and disagrees with the stored `buzz-communities` entry, either honor it or warn. Right now it silently diverges between the CLI and the UI, which sends people down the wrong path.
- Consider whether the buzz-mesh "relay unreachable" line should be scoped/labelled so it is not mistaken for a chat connectivity error (cf. #4342).

### Environment

- macOS (Darwin 25.4.0), Apple silicon
- Buzz Desktop 0.5.5
- Hosted community on `communities.buzz.xyz`

### Possibly related

- #4342 — buzz-mesh reports "relay unreachable" while the relay is reachable (same misleading log line, different subsystem)
- #3283 — local dev seeds loopback hosts as separate communities
- #2816 — self-host onboarding never offers a relay URL

Start with the desktop UI's relay-selection path and the tauri://localhost LocalStorage entry buzz-communities; compare it with BUZZ_RELAY_URL handling in the bundled CLI. Reproduce with a local relayUrl and verify completion by showing the target URL and underlying connection error, while ensuring production installs do not silently seed localhost.

Written by the indexing model from the issue text.