fix: match upstream CF-retry behavior; confine fronting to --dc-ip
Summary
Re-verified against upstream tg-ws-proxy's actual source — bridge.py, tg_ws_proxy.py, balancer.py, and the v1.8.0 release notes — not just the single "Fronting fallback" commit I'd looked at before. Issue #81's later reports (after #88/#89 landed) showed our port had drifted from upstream in two concrete ways:
1. Fronting is confined to --dc-ip connections in upstream, full stop. It's applied only to a direct connection to a DC's real IP, gated behind that DC having a known IP. Config::from_args() already suppresses the default --dc-ip (DC2/4) specifically when --cf-domain/--default-domains is set, so CF becomes the only path — and upstream's own v1.8.0 release notes document that the fix for "fronting failed: TimeoutError" + "WS connect timed out" is to clear --dc-ip so fronting is never attempted, not to make it reachable without one. #89 did the opposite. Reverted; --fronting-domain is now clearly documented as requiring --dc-ip, with a startup warning if it's set without effect.
2. Our per-DC CF-proxy cooldown had no upstream equivalent, and was the actual root cause of the "DC2 loops into TCP" reports. Upstream's _cfproxy_fallback retries every configured domain fresh on every single connection — no failure memory at all (balancer.py only remembers the last successful domain as a "try this first" hint, never blocks anything). Our --cf-fail-cooldown blocked all domains for a DC for 60s after any single failure, so with --cf-balance/--default-domains (many domains), one flaky domain was enough to knock out CF entirely for a full minute — forcing every connection in that window into the fronting/TCP fallback instead. Removed the cooldown gate from all three CF-proxy call sites.
The fronting fail-cooldown from #89 (don't retry a failed fronting attempt on every connection) is legitimate and kept, just scoped back to the two --dc-ip call sites it was always meant for.
Fixed #81