Stage 4: lobby & social (matchmaking, friends, blocks, chat+nudge, invitations, profile, email, multi-player drop-out)

Engine: multi-player drop-out-and-continue with a per-game tile disposition (remove default / return), resigned seats skipped and excluded from the win, leaver rack never revealed; 2-player behaviour unchanged.

New domains (service/store, no HTTP yet): internal/social (friend request/accept graph, per-user blocks, per-game chat with nudge as a message kind, content filter via mvdan.cc/xurls/v2 + leet/separator normaliser + phone heuristic) and internal/lobby (in-memory variant-keyed matchmaking pool, friend-game invitations invite->accept with lazy 7-day expiry). account gains profile editing and the email confirm-code flow (Mailer seam: SMTP or log mailer).

Migration 00003_social.sql + regenerated jet. main wires the new services into the server (accessors for the Stage 6 handlers); robot substitution stays in Stage 5, REST/stream/push in Stage 6/8. Docs (PLAN, ARCHITECTURE, FUNCTIONAL+ru, TESTING, README) updated.

docs/ARCHITECTURE.md

@@ -87,8 +87,13 @@ arrive from a platform rather than completing a mandatory registration).
   a platform auto-provisions a durable account bound to that platform identity.
   Concretely, platform and email identities share one `identities` table keyed by
   a unique `(kind, external_id)`; email is an identity with `kind=email` and a
-  `confirmed` flag (the confirm-code flow lands later). Accounts and identities
-  use application-generated **UUIDv7** primary keys.
+  `confirmed` flag. The **email confirm-code flow** (Stage 4) binds an email to the
+  authenticated account: a 6-digit code (stored only as a SHA-256 hash, 15-minute
+  TTL, ≤ 5 attempts) is sent through a `Mailer` seam (an SMTP relay, or a
+  development log mailer when none is configured) and, once verified, attaches a
+  confirmed email identity. An email already confirmed by **another** account is
+  refused — adopting it would be a merge, which Stage 10 owns. Accounts and
+  identities use application-generated **UUIDv7** primary keys.
 - **Linking** is initiated from an authenticated profile: choose a platform →
   complete that platform's web-auth confirm → attach the identity to the
   current account.
@@ -162,10 +167,16 @@ Key points:
   timed out while asleep.
 - **Players**: auto-match is always 2 players; friend games are 2–4 players.
   `backend` owns turn order and the bag for any player count. A resignation or
-  timeout in a two-player game ends it with the other player winning; **richer
-  multi-player drop-out (a leaver's seat skipped while the rest play on, with a
-  per-game disposition of their tiles) is deferred to Stage 4**, when friend games
-  are formed.
+  timeout in a two-player game ends it with the other player winning. In a game
+  with **three or more seats** a resignation or timeout **drops that seat and the
+  rest play on** — the engine skips the resigned seat in the turn rotation and
+  excludes it from the win, finishing the game (the sole survivor wins) only once
+  one active seat remains, or by the ordinary end conditions among the active
+  seats. A per-game **drop-out tile disposition**, chosen at creation
+  (`dropout_tiles`: `remove` from play — the default — or `return` to the bag),
+  governs the leaver's rack, which is **never revealed** to the remaining players;
+  it is recorded for deterministic journal replay. (Two-player games end on the
+  first drop-out, so the disposition does not affect them.)
 - **Hint**: governed by two per-game settings — whether hints are allowed and the
   starting per-player allowance — plus a per-account hint **wallet**
   (`hint_balance`, spent after the allowance; top-ups are a later feature). A hint
@@ -197,17 +208,39 @@ within 10 seconds. Designed to be indistinguishable from a person.
 
 ## 8. Lobby & social
 
-- **Matchmaking** *(detail planned)*: a FIFO pool keyed by `(variant,
-  language)`; 10 s with no human match → substitute the robot.
-- **Friends**: add by friend list, internal ID, or platform deep-link.
-- **Block** settings independently suppress in-game chat and friend requests.
-- **Chat**: per-game, persisted, length-limited, suppressed by the block
-  setting.
-- **Nudge**: a player may nudge the opponent whose turn is awaited once per
-  hour; the opponent receives a platform-native notification.
-- **Profile**: `preferred_language` (en/ru), display name, linked platform
-  accounts, email (confirm-code binding), **timezone** (drives robot sleep;
-  default from platform/locale, user-editable), block toggles.
+- **Matchmaking**: an **in-memory** FIFO pool keyed by `variant` (the variant
+  fixes the board language), pairing the next two humans into a two-player
+  auto-match with the seat order randomised for first-move fairness. The pool is
+  lost on restart (players re-queue) and is anonymous, so it does not consult
+  blocks. The 10 s wait and the **robot substitution** for a missing human are
+  added in Stage 5.
+- **Friends**: a **request → accept** graph (one `friendships` table) — add by
+  friend list or internal ID now, by platform deep-link with Stage 8. Declining or
+  cancelling removes the pending request; blocking someone severs an existing
+  friendship.
+- **Block**: two independent **global** account toggles (`block_chat`,
+  `block_friend_requests`) **plus** a **per-user block list**. A per-user block is
+  applied mutually: it hides the pair's chat from each other and refuses friend
+  requests and game invitations between them.
+- **Friend games**: formed by **invitation → accept** (an `game_invitations`
+  record with one row per invitee). The 2–4 player game starts once **every**
+  invitee accepts; any decline cancels the invitation, and a pending invitation
+  expires after 7 days (enforced lazily on access).
+- **Chat**: per-game, persisted (kept with the game's archive), **≤ 60 runes**,
+  and **validated on input** — links, email addresses and phone numbers (including
+  lightly obfuscated forms) are rejected, since the chat is for quick reactions,
+  not contact exchange. Each message stores the sender's IP (forwarded by the
+  gateway in Stage 6) for moderation. A sender who has disabled chat cannot post,
+  and messages from a blocked sender are hidden from the viewer.
+- **Nudge**: folded into the chat as a `nudge` message kind. The player awaiting
+  the opponent may nudge **once per hour per game**; it is not allowed on one's own
+  turn. The platform-native delivery is wired with the gateway / platform
+  side-service (Stage 6 / 8).
+- **Profile**: `preferred_language` (en/ru), display name, email
+  (confirm-code binding, see §4), **timezone** (drives the away window and the
+  robot's sleep; user-editable), the daily **away window** and the block toggles —
+  all editable through `account.UpdateProfile`. Linked platform accounts and merge
+  are Stage 10.
 
 ## 9. Persistence
 
@@ -220,9 +253,14 @@ within 10 seconds. Designed to be indistinguishable from a person.
 - Tables: `accounts` (durable internal accounts; Stage 3 added the away-window
   columns `away_start`/`away_end` and the hint wallet `hint_balance`),
   `identities` (platform/email identities, unique `(kind, external_id)`),
-  `sessions` (revoke-only opaque-token hashes), and the Stage 3 game tables
-  `games`, `game_players`, `game_moves` (the move journal), `complaints` and
-  `account_stats`.
+  `sessions` (revoke-only opaque-token hashes), the Stage 3 game tables
+  `games` (Stage 4 added the `dropout_tiles` disposition column), `game_players`,
+  `game_moves` (the move journal), `complaints` and `account_stats`, and the
+  Stage 4 social/lobby tables `friendships` (the request/accept graph), `blocks`
+  (per-user blocks), `chat_messages` (per-game chat and nudges), `email_confirmations`
+  (pending confirm-codes) and `game_invitations` / `game_invitation_invitees`
+  (friend-game invitations). The matchmaking pool is **in-memory** and persists
+  nothing.
 - **Active games are event-sourced.** A game is a `games` row (pinned
   `variant`/`dict_version`, bag `seed`, the per-game settings, and a denormalised
   turn cursor) plus an append-only, decoded move journal (`game_moves`); the live
@@ -263,7 +301,9 @@ does not cover.
 Two channels: **platform-native push** (out-of-app, via the platform
 side-service — your-turn, nudge) and the **in-app live stream** (chat,
 opponent-moved, while the app is open). Backend emits notification intents;
-delivery fans out to the appropriate channel.
+delivery fans out to the appropriate channel. Stage 4 **persists** the
+notification-worthy events (chat messages and nudges) but does not yet deliver
+them: the gRPC stream to the gateway and the platform push arrive in Stage 6 / 8.
 
 ## 11. Observability