fix(mtproto): bump FakeTLS tolerance to 30s — 3 s default rejects real clients

Production deploy surfaced every Telegram-client attempt being refused
with:

  "cannot read client hello"
  error="timestamp \"2026-04-22 21:50:20 +0000 UTC\" is too old 3.038756662s"

mtg's DefaultTolerateTimeSkewness is 3 seconds. Normal network latency
plus a sub-second clock skew between the client and the proxy exceeds
that. Telegram's own reference configuration example recommends 5 s;
mtg docs show deployments commonly running at 30 s+. Set 30 s here so
real-world clients are actually accepted.

This is the root cause of "proxy not available" reported by the admin
after the v0.12.0 rollout; the dispatcher + secret + DC connectivity
all check out.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: jonnyzzz

internal/mtproto/runtime.go

@@ -142,6 +142,12 @@ func (r *Runtime) Start(ctx context.Context) error {
 			Concurrency:        uint(dispatcherCfg.MaxConnections),
 			DomainFrontingPort: uint(port),
 			DomainFrontingIP:   host,
+			// mtg's default tolerance is ~3 s, which rejects clients even
+			// with normal network latency + a sub-second clock skew. A real
+			// deployment saw every Telegram client attempt rejected with
+			// "timestamp … is too old 3.04 s". Bump to 30 s — matches mtg's
+			// upstream recommendation for real-world deployments.
+			TolerateTimeSkewness: 30 * time.Second,
 		})
 		if err != nil {
 			return fmt.Errorf("mtproto runtime: new proxy for %s: %w", b.FQDN, err)