Desktop client cannot connect to a self-hosted relay using a private CA (tokio-tungstenite pinned to webpki-roots)

**Describe the bug**

The desktop client cannot open a WebSocket to a self-hosted relay whose TLS certificate chains to a private/internal CA.

`tokio-tungstenite` is pinned to the `rustls-tls-webpki-roots` feature, which compiles in a fixed list of public CAs and cannot read the OS trust store. `native_websocket.rs` calls `connect_async(url)` with no custom `Connector`, so that feature decides everything and there is no way to supply an internal root.

The symptom is unusually confusing to diagnose: the webview's HTTP requests succeed, because those use system trust. So the app looks functional — you can authenticate, create channels and send messages — while the connection banner is permanently wrong and there is no live push. New messages only appear after a manual refresh. It reads like a server outage, but the client never attempts the WebSocket at all.

**Steps to reproduce**

1. Stand up a self-hosted relay behind TLS with a certificate issued by an internal CA that IS installed in the OS trust store.
2. In the desktop client choose "I already have a community" then "I'm a member or admin", and enter the relay URL as `https://relay.example.internal` (normalizeRelayUrl maps https to wss).
3. Authentication succeeds and HTTP-backed actions work, but no WebSocket is ever established. The sidebar shows "Can't reach the relay" while messages still send over HTTP.

**Expected behavior**

The client should be able to trust a CA that is already present in the operating system's trust store, so a self-hosted relay with an internal certificate works without patching and rebuilding.

Any of these would resolve it:

- switch the feature to `rustls-tls-native-roots`
- keep webpki-roots and add native roots alongside it
- build a custom `Connector` from OS roots, optionally plus an extra CA path supplied by config or env

**Version and platform**

- Buzz version: 0.5.0 (desktop .deb). Also verified still present on `origin/main` at `346ae8cad` on 2026-08-07.
- OS: Ubuntu 24.04.3 LTS

**Logs / additional context**

Relevant lines on main today:

- `Cargo.toml:123` — `tokio-tungstenite = { version = "0.29", features = ["rustls-tls-webpki-roots"] }`
- `desktop/src-tauri/Cargo.toml:86` — same
- `desktop/src-tauri/src/native_websocket.rs` — `connect_async(url)`, no `Connector`

Workaround we are using: change the desktop feature to `rustls-tls-native-roots` and rebuild. It is a one-line change and it works, but it means maintaining a fork and rebuilding on every release.

Two things that may be worth weighing:

- The self-hosting documentation points at private CAs, so this affects the documented deployment path rather than an exotic setup.
- `buzz-cli` is NOT affected. It is HTTP-only via reqwest → hyper-rustls → rustls-native-certs, so it uses the OS trust store and works against the same relay unpatched. That asymmetry between the CLI and the desktop client is what made this take a while to isolate.