docs(telegram): invert chat-gate strategy in docs; tune logs; i18n text

- Bake the final default-allow + mute-the-ineligible strategy into
  docs/ARCHITECTURE.md, docs/FUNCTIONAL.md (+_ru), platform/telegram/README.md,
  the deploy compose comment and the PRERELEASE tracker. The live test proved a
  per-user grant cannot exceed a deny-by-default group (Telegram intersects the
  chat default with the per-user permission), so the chat allows sending by
  default and the bot restricts the ineligible instead of granting the eligible.
- Lower the per-event chat_member trace and eligibility evaluation to Debug;
  keep the actual mute/unmute actions, the startup self-check and warnings at
  Info, so prod logs only what the bot did.
- Update game.searchingForOpponent (Searching -> Waiting for opponent / Поиск ->
  Ждём соперника) and the quickmatch e2e assertions to match.

PRERELEASE.md

@@ -41,7 +41,7 @@ the edge before prod. Each phase maps back to the owner's raw pre-release TODO l
 | DV | Dictionary version hygiene: CI + image/compose seed track the current release (`v1.2.1`); a **seed-drift guard** records the flat dir's seed in an authoritative `.seed_version` marker so a bumped build seed on a live volume is ignored (it can't relabel live bytes — which would mis-serve the dictionary + void games pinned to the prior label); `DICT_VERSION` is the fresh-volume seed only, a live contour migrates through the admin console | owner ad-hoc | **done** |
 | TX | Telegram egress off the main host: split the connector into a home **validator** (Mini App / Login-Widget HMAC, no VPN, no Bot API — so game login no longer depends on Telegram being reachable) and a remote **bot** (Bot API long-poll + `sendMessage`) that holds **no inbound port** and dials the gateway over a reverse **mTLS bot-link** (`pkg/proto/botlink/v1`); the gateway funnels out-of-app push (fire-and-forget, at-most-once) and the backend admin broadcasts (a relay that awaits the bot's ack) down the link. The bot is Telegram-rate-limited; **one bot now**, with seams (a bot registry + `owns_updates` + command ids) for N later; **no 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; certs from `deploy/gen-certs.sh`). 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** (Stage 18). | owner ad-hoc | **done** (code + test contour; prod wiring → Stage 18) |
 | AG | Anti-abuse IP ban + honeypot/honeytoken (prod-only): a fail2ban-style in-memory `ratelimit.Banlist` keyed by client IP, fed by sustained rate-limiter rejections (the IP-keyed public/email/admin classes — the user class stays the soft-flag's concern), a **honeypot** decoy path (the contour caddy tags `/.env`, `/.git`, `/wp-*`, … with `X-Scrabble-Honeypot` and routes them to the gateway), and a **honeytoken** (`GATEWAY_HONEYTOKEN`, a planted bearer). The `abuseGuard` edge middleware refuses a banned IP with **429** before any work — closing the R3 gap that the static SPA/landing was outside the token bucket. Off by default — it keys by the real client IP the shared-NAT test contour does not expose (detection still logs there); enabled in prod via `GATEWAY_ABUSE_BAN_ENABLED`. Operators see + lift bans on the console **Throttled** page; the gateway syncs its active set to the backend (`/api/v1/internal/bans/sync`, `internal/banview`) every 30 s and applies operator unbans. | owner ad-hoc | **done** (code + test contour; ban enabled in prod → Stage 18) |
-| CM | Channel-chat moderation + promo bot: a second standalone bot in the bot container answers `/start` with a localized message + a **URL** button into the **main** bot's Mini App (`?startapp`; a `web_app` button would sign initData with the promo token, which the main validator rejects). The **main** bot gates write access in a channel's linked discussion chat — granting on join when the Telegram user is registered and neither admin-suspended nor holding a new **`chat_muted`** role, and revoking/granting on the matching moderation change for a member currently in the chat (a `getChatMember` guard, since bots cannot list members). Eligibility = `registered AND NOT suspended AND NOT chat_muted` (the game suspension dominates), resolved once in the backend and reached two ways: the bot's join-time unary `ResolveChatEligibility` over the existing mTLS bot-link, and a backend `chat_access_changed` event → gateway → `ChatGate` command (idempotent, so a temporary-block-expiry sweeper may over-emit). No schema change — `chat_muted` reuses `account_roles`. | owner ad-hoc | **done** |
+| CM | Channel-chat moderation + promo bot: a second standalone bot in the bot container answers `/start` with a localized message + a **URL** button into the **main** bot's Mini App (`?startapp`; a `web_app` button would sign initData with the promo token, which the main validator rejects). The **main** bot gates write access in a channel's linked discussion chat. The chat **allows sending by default** and the bot only restricts (Telegram intersects the chat default with the per-user permission, so a per-user grant cannot exceed a deny-by-default group): it **mutes** a member who is not registered or is admin-suspended or holding a new **`chat_muted`** role, and **un-mutes** an eligible one it had muted, for a member currently in the chat (a `getChatMember` guard, since bots cannot list members). Eligibility = `registered AND NOT suspended AND NOT chat_muted` (the game suspension dominates), resolved once in the backend and reached two ways: the bot's `ResolveChatEligibility` on a `chat_member` event over the existing mTLS bot-link, and a backend `chat_access_changed` event → gateway → `ChatGate` command (emitted on block/unblock, a `chat_muted` change, a first registration, or a temporary-block expiry via a sweeper; idempotent). No schema change — `chat_muted` reuses `account_roles`. | owner ad-hoc | **done** |
 | → | Stage 18 — prod contour deploy | — | see [`PLAN.md`](PLAN.md) |
 
 ## Key findings (these reshaped the raw list — read before starting a phase)
@@ -611,13 +611,17 @@ Then Stage 18.
     the sweeper window (unit + integration); gateway hub `ResolveChatEligibility` + the chat-gate command; bot
     `chat_member` grant + `ApplyChatGate` getChatMember-guard; promo `/start` localization + URL button; config
     parsing.
-  - **Post-contour-test fixes (same PR):** a live test surfaced gaps. (1) **Join detection** — a
-    default-deny discussion group reports a present member as `restricted`, not `member`, so the grant
-    trigger now fires for any eligible in-chat member (`member` or `restricted`) still lacking the send
-    right, with a loop guard (skip when send is already allowed, so the bot's own grant does not
-    re-fire); revoking a now-ineligible user stays the chat-gate path's job, so this never fights a
-    `chat_muted`/block. (2) **Join-before-register** — a user who joins before registering is covered by
-    no `chat_member` event, so `ProvisionTelegram` now reports first contact and the Telegram auth
-    handler emits `chat_access_changed` on it. (3) **Observability** — a startup self-check logs whether
-    the bot is an admin-with-restrict in the chat (it caught a misconfigured `TELEGRAM_CHAT_ID` set to a
-    channel id instead of the discussion-group id), plus per-event grant-path logging.
+  - **Post-contour-test fixes (same PR):** a live test drove three corrections. (1) **Strategy
+    inversion (the key one)** — the original "group default no-send, bot grants the eligible" cannot
+    work: Telegram intersects the chat default with each user's permission, so a per-user grant never
+    exceeds a deny-by-default group (the bot set `can_send=true` yet the user still could not write).
+    The group now **allows sending by default** and the bot only **restricts** — it mutes an ineligible
+    member (unregistered / admin-suspended / `chat_muted`) and un-mutes an eligible one it had muted,
+    acting only when the current state differs (idempotent; the bot's own change is skipped by matching
+    the actor id to the bot). A present member in a default-allow group can appear as `restricted` with
+    `is_member`, so the gate reads both. (2) **Join-before-register** — a user who joins before
+    registering is covered by no `chat_member` event, so `ProvisionTelegram` now reports first contact
+    and the Telegram auth handler emits `chat_access_changed` on it. (3) **Observability** — a startup
+    self-check logs whether the bot is an admin-with-restrict in the chat (it caught a misconfigured
+    `TELEGRAM_CHAT_ID` set to a channel id, not the discussion-group id); the per-event trace is at
+    Debug, the actual mute/unmute and warnings at Info.