Address review of the active-game limit lock:
- Live-event GameViews (opponent_moved, match_found, game_started, ...) did
not carry game_kind, so a lobby patch from an event zeroed a game's kind
and the client's per-kind count under-counted — a capped kind read as
free (a disabled start instead of the lock, and a wrong per-kind result).
Thread Kind through notify.GameSummary → the event GameView.
- New Game screen refreshes the lobby games on mount so the per-kind count
reflects the current set, not a stale cached snapshot.
- The guest funnel's login button routes to the profile screen (the account
controls), not settings.
- Copy: the guest prompt is "sign in to use all the game's features"; the
durable notice is "finish your active games to start a new one".
Regression tests: the notify opponent-moved payload carries kind; the client
lock locks only the reached kind (vs_ai at cap leaves random open).
Carry the caller's per-tier active-game caps and each game's kind on the
wire (Profile.game_limits + GameView.kind, additive FBS + gateway transcode
+ client codec, committed regen). The New Game screen counts the player's
active games per kind from the lobby and locks a capped start: an outline
button with a lock that opens a funnel modal instead of a game -- a sign-in
prompt for a guest, a "finish a current game first" notice for a signed-in
account (native Telegram popup, in-app modal elsewhere). The lock lifts via
the existing profile refetch after a guest->durable upgrade.
Remove the lobby's old at_game_limit New-Game tab disable + notice: the flag
(now the random-kind cap) conflicted with the per-kind lock -- it hid the
screen where the lock lives and wrongly blocked an unfulfilled kind. The New
Game tab is always enabled; the per-kind start lock is the only gate. The
at_game_limit wire field stays (unused by the client) for a later cleanup.
Tests: client lock logic + codec kind/game_limits roundtrip + gateway
transcode encode + native popup builders (unit); a mock e2e for the lock
badge and the modal.