Support SOCKS5 proxy egress in the Tauri XMPP bridge

[mremond]

Summary

The native Rust XMPP bridge (apps/fluux/src-tauri/src/xmpp_proxy/) currently dials the upstream XMPP server with a bare TcpStream::connect (STARTTLS:5222 / direct-TLS:5223) and ignores any system proxy. On networks where a proxy is required for egress (corporate networks, Tor, restricted environments), the bridge cannot reach the server and connecting fails outright.

Scope

This is the upstream hop (bridge → server), distinct from the loopback hop (WebView → bridge) addressed in #493 / #499. #499 only forces the loopback hop direct past a declared proxy; it does not route egress through one.

Proposal

Teach try_connect_endpoint to optionally dial through a SOCKS5 proxy:

• Add a SOCKS5 client (e.g. tokio-socks) and wrap the TCP connect for both ConnectionMode::Tcp (STARTTLS) and ConnectionMode::DirectTls.
• Resolve the proxy from the conventional env vars (all_proxy/ALL_PROXY, then https_proxy/http_proxy) and/or an explicit app setting; no proxy configured → keep today's direct connect.
• Decide DNS handling (resolve locally vs. let the SOCKS5 proxy resolve the hostname — the latter is required for Tor .onion and avoids DNS leaks).
• Surface proxy-connect failures in the existing BridgeEndReason / close-reason machinery so the UI shows a real cause.

Out of scope (for now)

• HTTP CONNECT proxies — could be a follow-up; SOCKS5 covers the common egress + Tor cases.
• A full in-app proxy configuration UI (start with env-var detection).

Notes

• The WebView side (HTTP resources, avatars/media) is a separate consideration; this issue is specifically the XMPP TCP egress in the bridge.