feat(gateway): temporary IP ban (fail2ban) fed by rejections + honeypot/honeytoken

Add a prod-only, in-memory IP ban enforced at the edge, fed by three signals:
sustained rate-limiter rejections (the IP-keyed public/email/admin classes — the
user class stays the backend soft-flag's concern), a honeypot decoy-path hit (the
contour caddy tags decoys with X-Scrabble-Honeypot and routes them to the gateway),
and a honeytoken (a planted bearer, GATEWAY_HONEYTOKEN). A banned IP is refused with
429 by the abuseGuard middleware before any work — covering the Connect edge, the
live stream and the static SPA/landing the per-op limiter never gated.

The ban is off by default: it keys by the real client IP the shared-NAT test contour
does not expose, so a ban there would be self-inflicted; detection still logs in the
contour, only the ban action is gated (GATEWAY_ABUSE_BAN_ENABLED). Rejection bans last
GATEWAY_ABUSE_BAN_DURATION; tripwire/honeytoken hits are near-zero-false-positive and
earn longer fixed bans. Each ban increments gateway_abuse_banned_total{reason}.

Operators see and lift active bans on the admin console's Throttled page; the gateway
syncs its active set to the backend every 30s (POST /api/v1/internal/bans/sync,
backend/internal/banview) and applies the operator unbans the response returns.

PRERELEASE phase AG. Docs baked into ARCHITECTURE / FUNCTIONAL (+ru) / both READMEs.

docs/FUNCTIONAL.md

@@ -295,8 +295,14 @@ recently throttled users/IPs the gateway reported (an in-memory window — it re
 a backend restart) and the accounts currently carrying the soft **high-rate flag**. An
 account sustaining rejections past a tunable threshold is flagged automatically —
 the marker is reversible, shown as a badge in the user list and on the user card, and
-**never blocks play**; the operator reviews and clears it from the user card. There is
-no automatic ban.
+**never blocks play**; the operator reviews and clears it from the user card. The
+account flag itself is never a ban. In **production** the same page also lists the
+**active IP bans** the gateway is enforcing: a temporary block of a client IP that
+floods the service past a threshold, or trips a hidden **honeypot** path or a planted
+**honeytoken** — a high-confidence sign of a scanner or hostile bot, never a normal
+player. Each ban shows its reason and expiry with an **Unban** action; bans auto-expire
+and the operator can lift one early. IP bans are a production-only safeguard — the
+shared test environment cannot tell its clients apart, so it does not enforce them.
 
 The console also lets an operator **manually block** an account — the hard counterpart to the
 soft high-rate flag. From the user card the operator blocks the account **permanently** or