Trust platform root certificates for relay WebSocket TLS

[ilkonovalov]

Problem

crates/buzz-ws-client/src/connection.rs connects to the relay with
tokio_tungstenite::connect_async(...), which uses the default TLS
configuration. The workspace enables:

tokio-tungstenite = { version = "0.29", features = ["rustls-tls-webpki-roots"] }

rustls-tls-webpki-roots compiles in a fixed copy of the Mozilla public root
list. It does not consult the OS trust store or SSL_CERT_FILE, and there is
no code path to inject an extra trust anchor. As a result, a client/agent
cannot connect (wss://) to a relay whose certificate chains up to a private
or internal CA — the handshake terminates with invalid peer certificate: UnknownIssuer. This blocks any self-hosted deployment that terminates TLS
with an organization-issued certificate.

Change

Switch the TLS feature to rustls-tls-native-roots:

-tokio-tungstenite = { version = "0.29", features = ["rustls-tls-webpki-roots"] }
+tokio-tungstenite = { version = "0.29", features = ["rustls-tls-native-roots"] }

The client now trusts the platform trust store, which includes the public CAs
and any operator-installed CA. Public relays keep working; relays behind a
private CA start working without any client code change.

Deployment note (containers / Helm): because trust now comes from the
platform store, operators of a containerized relay can add a private CA the
standard way — provision it into the container's trust store (e.g. mount the
CA bundle into /etc/ssl/certs via the chart) — with no rebuild of the binary.

Caveat / alternative

native-roots requires the runtime to actually have a trust store. Minimal
images (scratch / distroless) that ship no CA bundle would start with an empty
root set and fail TLS even to public relays; such images must include
ca-certificates.

If a zero-regression path is preferred, an alternative is to build an explicit
rustls::ClientConfig in connection.rs that seeds roots from webpki-roots
(so public CAs always work) and adds native certs plus an optional CA file
(e.g. from an env var), then pass it via
connect_async_tls_with_config(..., Some(Connector::Rustls(...))). Happy to
switch to that approach if maintainers prefer it.

[ptahdunbar]

This is CI-green and correctly fixes the workspace-level tokio-tungstenite dependency, which covers buzz-acp, buzz-ws-client, and the test/pairing clients since they all inherit it via workspace = true.

One gap: desktop/src-tauri/Cargo.toml redeclares tokio-tungstenite independently rather than inheriting from the workspace, so it still has rustls-tls-webpki-roots after this change. That means the desktop app's native WebSocket client is unaffected by this PR and issue #2940 (desktop ignoring macOS system-trusted private CAs) would remain open. Same symptom, same fix — just needs the identical feature swap applied to desktop/src-tauri/Cargo.toml + its own Cargo.lock. Ran into this independently on a Zscaler-proxied machine and can confirm the fix works once both spots are covered.