feat(telegram): split connector into home validator + remote bot

Move all Telegram egress off the main host. The single connector held the
bot token, long-polled Telegram and answered the gateway/backend over the
trusted internal network, so the whole component (including login validation)
shared fate with its VPN sidecar. Split it into two binaries that share the
token:

- cmd/validator (home, no VPN): Mini App initData + Login Widget HMAC only,
  never calls the Bot API. The gateway dials it for Telegram auth, so game
  login is now independent of Telegram reachability.
- cmd/bot (remote): Bot API long-poll + sendMessage, the only component
  reaching Telegram. It holds no inbound port — it dials the gateway over a
  new reverse mTLS bot-link (pkg/proto/botlink/v1) and executes the send
  commands the gateway pushes.

The gateway funnels sends to the bot-link: out-of-app push is fire-and-forget
(at-most-once, dropped if no bot is connected); the backend admin broadcasts
reach a gateway-served relay that forwards them and awaits the bot's ack
(SendToUser/SendToGameChannel contract preserved). mTLS (pkg/mtls) is the one
inter-service link that leaves the trusted segment; validator<->gateway and
the relay stay plaintext internal. The bot is Telegram-rate-limited.

One bot now; the gateway bot registry, an owns_updates flag and per-command
ids leave seams for N later. Webhook rejected (one URL per token, adds inbound
+ a static address).

The unified test contour runs the split (the bot keeps its VPN sidecar and
dials the gateway by its internal name; bot-link certs from deploy/gen-certs.sh,
generated in CI). The prod wiring — the bot on a separate host (no VPN), the
gateway bot-link port published, PROD_ certs with scheduled rotation, an SSH
deploy of both hosts together — is the deferred final stage (PRERELEASE.md TX,
Stage 18).

Docs: ARCHITECTURE, PRERELEASE (phase TX), platform/telegram + gateway +
backend + deploy READMEs, FUNCTIONAL(+ru), CLAUDE.md, .env.example.

backend/README.md

@@ -103,7 +103,7 @@ second listener — `internal/pushgrpc`, a gRPC server (`BACKEND_GRPC_ADDR`) str
 live events (your-turn, opponent-moved, chat, nudge, match-found, notify) to the
 gateway. The gateway-only `POST /api/v1/internal/push-target` (a user's
 Telegram `external_id`, language and `notifications_in_app_only` flag) lets the gateway
-route out-of-app push to the Telegram connector; the Telegram login
+route out-of-app push to the Telegram bot over the gateway bot-link; the Telegram login
 seeds a new account's language and display name from the launch fields, and the
 `accounts.notifications_in_app_only` flag (default true).
 `accounts.is_guest` marks an ephemeral guest — a durable row
@@ -116,8 +116,9 @@ pipeline, the online **dictionary update** (upload the `scrabble-dawg-vX.Y.Z.tar
 archive, preview the per-variant word diff, then install + activate — `internal/dictadmin` +
 `engine.DiffWords` / `Registry.LoadAvailable`, written to per-version subdirectories of the
 `BACKEND_DICT_DIR` volume with the active version persisted in `dictionary_state`), and operator **broadcasts** via a
-backend Telegram-connector client (`internal/connector`, `BACKEND_CONNECTOR_ADDR`) — each
-broadcast renders through the single bot in an operator-chosen language. There is one bot,
+backend client (`internal/connector`, `BACKEND_CONNECTOR_ADDR`) that calls the gateway's
+**bot-link relay** — each broadcast renders through the bot in an operator-chosen language
+and the relay awaits the bot's delivery ack. There is one bot,
 so `/internal/push-target` returns the recipient's `preferred_language` as the render
 language for out-of-app push; no per-bot routing remains. The console also manages the **advertising banner** (`/_gm/banners` +
 `/_gm/banner-settings`, `internal/ads`): operator campaigns with a percent weight, an optional
@@ -170,7 +171,7 @@ internal/lobby/      # auto-match (DB-backed open games + robot substitution) +
 internal/robot/      # human-like robot opponent: account pool, seed-derived strategy, move driver
 internal/adminconsole/ # server-rendered admin console (Go templates + embedded CSS, view models), served at /_gm
 internal/ads/        # advertising banner: campaigns + bilingual messages + display timings, weighted-rotation feed (ActiveSet)
-internal/connector/  # backend gRPC client to the Telegram connector (operator broadcasts)
+internal/connector/  # backend gRPC client to the gateway bot-link relay (operator broadcasts)
 internal/ratewatch/  # gateway rate-limit reports: episode window for the console + the high-rate auto-flag
 ```
 
@@ -201,7 +202,7 @@ internal/ratewatch/  # gateway rate-limit reports: episode window for the consol
 | `BACKEND_SMTP_USERNAME` | — | SMTP user; empty relays without authentication. |
 | `BACKEND_SMTP_PASSWORD` | — | SMTP password. |
 | `BACKEND_SMTP_FROM` | `no-reply@localhost` | Envelope/From address for confirm-codes. |
-| `BACKEND_CONNECTOR_ADDR` | — | Telegram connector gRPC address for admin-console operator broadcasts. Empty disables broadcasts. |
+| `BACKEND_CONNECTOR_ADDR` | — | the gateway bot-link relay gRPC address for admin-console operator broadcasts. Empty disables broadcasts. |
 | `BACKEND_GUEST_REAP_INTERVAL` | `1h` | How often the abandoned-guest reaper sweeps. |
 | `BACKEND_GUEST_RETENTION` | `720h` | Account age past which a guest with no game seat is deleted. |
 | `BACKEND_HIGHRATE_FLAG_THRESHOLD` | `1000` | Gateway-reported rejected calls within the window past which an account is soft-flagged. |

backend/internal/connector/client.go

@@ -1,10 +1,10 @@
-// Package connector is the backend's gRPC client for the Telegram platform
-// connector side-service. The admin console uses it to send operator broadcasts:
-// a direct message to one user, or a post to the game channel, through the single
-// bot. The connector lives on the trusted internal network, so the connection uses
-// insecure (plaintext) transport credentials (docs/ARCHITECTURE.md §12). It mirrors
-// gateway/internal/connector, narrowed to the two broadcast methods the admin
-// surface needs.
+// Package connector is the backend's gRPC client for operator broadcasts: a direct
+// message to one user, or a post to the game channel. It calls the gateway's
+// bot-link relay (which forwards the send to the remote bot over the reverse mTLS
+// link and reports back whether it was delivered). The relay lives on the trusted
+// internal network, so the connection uses insecure (plaintext) transport
+// credentials (docs/ARCHITECTURE.md §12). It speaks the Telegram service contract,
+// narrowed to the two broadcast methods the admin surface needs.
 package connector
 
 import (