R3: dashboards, docs and tracker bake-back

- Edge/UX dashboard: aggregate request-rate vs rejection-rate panel
  (gateway_rate_limited_total by class; no per-user labels).
- ARCHITECTURE §2/§11/§12/§13: body cap + explicit h2c sizing, the rate-limit
  observability pipeline and auto-flag policy, the admin-limiter note (and the
  caddy-path gap), the landing container topology; fixed the stale 120/min
  per-user figure.
- FUNCTIONAL (+_ru): the Throttled view and the reversible high-rate flag.
- gateway/backend/deploy READMEs, TESTING.md, root CLAUDE.md updated.
- PRERELEASE.md: R3 interview decisions + implementation refinements logged;
  tracker R3 -> done (this PR implements it; CI gates the merge).

docs/FUNCTIONAL.md

@@ -171,3 +171,11 @@ applied after a reload). When a Telegram connector is configured an operator can
 **message a user** (by their Telegram identity) or **post to the game channel**.
 State-changing actions are protected by a same-origin check; the console tracks no
 operator identity.
+
+The console also surfaces **rate-limit abuse** (R3): a **Throttled** page lists the
+recently throttled users/IPs the gateway reported (an in-memory window — it resets on
+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.