Desktop: no client-side connection/TLS logging — TLS failures and refused ports are indistinguishable

**Is your feature request related to a problem?**

When the desktop client fails to reach a self-hosted relay, there is no client-side logging to tell the operator *why*. The Tauri backend has no `tauri-plugin-log` / `env_logger` / `tracing-subscriber`, and `RUST_LOG` is ignored, so no log file is produced (see also #5157: "I cannot find any log files from client").

Connection failures are collapsed to a couple of coarse UI strings that erase the actual cause:

- A TLS handshake failure (e.g. the private-CA / webpki-roots case in #5197) and a refused/unreachable port **both** render as the same "Can't reach the relay" banner.
- A community-host mismatch renders as a generic 404.

Because the webview's HTTP requests use the system trust store and succeed, the app looks healthy while the WebSocket silently never connects — so the operator has no signal at all that TLS was the problem. Diagnosing #5197 required reading the upstream source.

**Describe the solution you'd like**

Minimal, opt-in connection diagnostics on the desktop client:

- A log line (honoring `RUST_LOG`, or written to a discoverable log file) at each WebSocket connect attempt: the resolved `wss://` URL, and on failure the underlying error class — TLS/certificate error vs. connection refused vs. DNS failure vs. HTTP 404 host-miss — rather than one flattened string.
- Ideally surface the distinction in the UI banner too (e.g. "TLS certificate not trusted" vs "relay unreachable" vs "no community configured for this host").

**Describe alternatives you've considered**

None that work from the operator side — the client emits nothing, so the only current recourse is reading upstream source or packet-capturing the handshake.

**Additional context**

Filed from packaging Buzz relay for StartOS (Start9). This is the diagnosability half of the self-hosting story; the underlying trust fix is tracked in #5197 and the single-host binding in #4952 / #4953.