feat: port domain-fronting fallback from upstream (fix issue #81)

Summary

Ports the "domain fronting fallback" from upstream Flowseal/tg-ws-proxy@c8f6f8c, addressing #81.

What it does: when direct WebSocket connects to a Telegram DC keep timing out (a sign of SNI-based DPI blocking), the proxy retries using an unrelated, presumably-unblocked domain as the TLS SNI while still connecting to Telegram's real DC IP and using the real DC domain as the HTTP Host. DPI that filters by SNI sees an allowed domain; the actual (TLS-encrypted) request still reaches Telegram normally.

• New flags: --fronting-domain <DOMAIN> (e.g. sprinthost.ru, disabled unless set) and --fronting-cooldown <SECS> (default 1800 = 30 min "sticky" window after a fronted connection succeeds, matching upstream).
• TLS certificate verification is unconditionally skipped on connections using this fallback — the real Telegram cert can never match a fronted SNI, so hostname verification would always fail. This is inherent to the technique (matches upstream's own behavior), not a regression, and only applies to this one fallback path.
• The sticky window also applies to background connection-pool refills, so a client doesn't get handed an un-fronted pooled connection while fronting is active.
• tokio_tungstenite's TLS helper always derives SNI from the request's own host with no override hook, so the SNI-override path does the TLS handshake manually via tokio_rustls and then hands the established stream to client_async_with_config for the WS upgrade — same result type, no behavior change on the non-fronted path.