feat(lobby): cap simultaneous quick games at 10

Limit a player to 10 active quick games (auto-match + AI); friend games created
by invitation are not counted. At the cap the backend refuses both new-game
entry points — quick enqueue and invitation creation — with 409
game_limit_reached, while accepting an incoming invitation stays allowed, so
friend games are capped from the other end. The lobby disables "New Game" and
shows a low-emphasis notice, driven by a new at_game_limit flag on games.list
(no per-event payload: a turn change does not move the count, and the lobby
already re-fetches games.list on entry and every game event).

- game.MaxActiveQuickGames + Store/Service.CountActiveQuickGames (active/open
  seats, no game_invitations row; hidden games still count -> dedicated count)
- Server.ensureUnderGameLimit gating handleEnqueue + handleCreateInvitation;
  game.ErrGameLimitReached -> 409 game_limit_reached
- FB GameList.at_game_limit (regenerated Go + TS) through the gateway transcode
  and UI codec; gameListDTO + lobbycache snapshot + Lobby.svelte + i18n
- tests: integration count rule + HTTP gate + accept bypass; server error map;
  gateway transcode round-trip; UI codec + lobbycache unit; e2e gamelimit
- docs: PRERELEASE (GL), FUNCTIONAL(+ru), ARCHITECTURE 8, UI_DESIGN, backend README

docs/ARCHITECTURE.md

@@ -467,6 +467,18 @@ disguised robot stays indistinguishable from a person.
   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.
 - **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