feat(backend): per-tier, per-kind active-game limits with a guest funnel

Cap a player's simultaneous unfinished games per kind (vs_ai, random,
friends) with independent guest and durable-account tiers, held in a new
single-row backend.config table (-1 = unlimited) behind an in-memory cache
and editable live in the admin console (/_gm/limits). Each game is tagged
with games.game_kind on creation.

This replaces the earlier flat MaxActiveQuickGames=10 combined cap: the
per-tier/kind config is the single mechanism, enforced at the same handler
gate (ensureUnderGameLimit by kind on lobby/enqueue) plus the durable
friends cap in CreateInvitation. game.Service.AtGameLimit only resolves the
tier and counts; the limit policy stays at the request edge.

Guests are now refused friend requests, friend-code redemption,
befriend-in-game and invitation creation outright (403 guest_forbidden) --
previously only the UI hid these.

Admin: a kind column in both game lists and the config editor.

Defaults: guest 1 vs_ai / 1 random / 0 friends; durable 10 / 10 / 10.

docs/ARCHITECTURE.md

@@ -650,18 +650,27 @@ in either direction (the enqueue excludes the caller's `BlockedWith` set);
   game is `open` the starter may move on their turn, but resign, chat and nudge are
   refused (no opponent yet) and the lobby and opponent card show a "searching for
   opponent" placeholder.
-- **Simultaneous-game cap**: a player may hold at most `game.MaxActiveQuickGames`
-  (**10**) active quick games. `game.Service.CountActiveQuickGames` counts the games
-  seating the account in status `active` or `open` **without** a linked
-  `game_invitations` row — friend games are excluded, and hidden games still occupy a
-  slot, so it is a dedicated count rather than a filter over the lobby list. The backend
-  **gate** (`Server.ensureUnderGameLimit`) refuses **both** new-game entry points at the
-  cap — `POST /lobby/enqueue` and `POST /invitations` — with **409 `game_limit_reached`**;
-  **accepting** an invitation (`POST /invitations/:id/accept`) is never gated, so friend
-  games are capped only at initiation. The lobby learns the state from a boolean
-  **`at_game_limit`** carried on the `games.list` response — the lobby already re-fetches
-  that on entry and on every game event, so the flag needs no separate request or
-  per-event payload; while it is set the client disables **New Game** and shows a notice.
+- **Active-game caps (per tier, per kind)**: a player's simultaneous unfinished games are
+  capped per **kind** — `vs_ai`, `random` (quick auto-match), `friends` — with independent
+  **guest** and **durable-account** tiers. The caps live in the single-row `backend.config`
+  table (`-1` = unlimited), read once at boot into an in-memory cache (`internal/gamelimits`)
+  and refreshed in place when an operator edits them in the admin (`/_gm/limits`) — so a
+  login or game-create never queries the table. The seeded defaults are guest **1 vs_ai / 1
+  random / 0 friends** and durable **10 / 10 / 10** (this replaced the earlier flat
+  `MaxActiveQuickGames`=10 combined cap). Each game is tagged with `games.game_kind` on
+  creation (0 = an untagged game, never gated). `game.Service.AtGameLimit` resolves the
+  account's tier, then counts its `active`/`open` games of the kind (hidden games still
+  occupy a slot) against the cap. The gate (`Server.ensureUnderGameLimit`) refuses
+  `POST /lobby/enqueue` — random or vs_ai per the request — with **409 `game_limit_reached`**;
+  the `POST /invitations` (friends) path enforces the durable friends cap the same way and
+  refuses a **guest** outright with **403** (guests cannot use friends — the same guest gate
+  covers friend requests and friend-code redemption). **Accepting** an invitation
+  (`POST /invitations/:id/accept`) is never gated, so friend games are capped only at
+  initiation. The lobby learns the random-kind state from a boolean **`at_game_limit`** on
+  the `games.list` response — already re-fetched on entry and every game event; the client
+  additionally counts the listed games per kind against the per-tier caps it reads in the
+  profile, locking a kind's New-Game entry (a login funnel for a guest, an already-at-limit
+  note for a durable account) when that kind is full.
 - **Friends**: two add paths over one `friendships` table. A **one-time
   code** the to-be-added player issues (a `friend_codes` row: 6-digit numeric,
   SHA-256-hashed, **12 h** TTL, one live code per issuer, single-use, redeem