Stage 11: account linking & merge (email + Telegram Login Widget)

Link an email (confirm-code) or Telegram (web Login Widget) to the current
account; if the identity already has its own account, merge the two into the
one in use (the current account is primary, except a guest initiator whose
durable counterpart wins). The merge runs in one transaction
(internal/accountmerge): stats + hint wallet summed, paid_account ORed,
identities/games/chat/complaints transferred, friends/blocks de-duplicated,
the secondary kept as a merged_into tombstone so a shared finished game's
no-cascade FKs hold; a shared active game blocks the merge.

- migration 00009: accounts.paid_account, merged_into, merged_at (+ jetgen)
- internal/link orchestrator; session.RevokeAllForAccount on merge
- connector ValidateLoginWidget RPC + loginwidget HMAC validator
- edge ops link.email.request/confirm/merge, link.telegram.confirm/merge;
  supersedes the Stage 8 email.bind.* surface (request never reveals 'taken'
  before the code is verified, so a probe cannot enumerate addresses)
- UI Profile link section + irreversible-merge dialog; Telegram web sign-in
- focused regression tests (merge core, guest inversion, active-game refusal,
  finished-shared-game kept), gateway transcode + connector + UI codec/e2e
- docs: PLAN, ARCHITECTURE 3/4/9, FUNCTIONAL(+ru), module READMEs

PLAN.md

@@ -44,7 +44,7 @@ independent (see ARCHITECTURE §9.1).
 | 8 | UI — social/account/history (friends, blocks, invitations, profile edit, stats, history/GCG) | **done** |
 | 9 | Telegram integration (bot side-service, deep-link, push) | **done** |
 | 10 | Admin & dictionary ops (complaint review, version reload) | **done** |
-| 11 | Account linking & merge | todo |
+| 11 | Account linking & merge | **done** |
 | 12 | Polish (observability, perf with evidence, deploy) | todo |
 
 Scaffolding is incremental: `go.work` lists only existing modules; each stage
@@ -738,6 +738,64 @@ Open details: deployment target/host; dashboards; load expectations.
     (the console is server-rendered Go). The Go workflows already span
     `./backend/... ./gateway/... ./pkg/...`; integration stays `./backend/...`.
 
+- **Stage 11** (interview + implementation):
+  - **Scope = link-via-confirm + merge for email and Telegram** (interview): the
+    current account is the merge **primary**; a linked identity that already has its
+    own account is merged into the current one and the secondary is retired as an
+    **audit tombstone** (`accounts.merged_into`/`merged_at`, migration `00009`
+    + jetgen). Linkable this stage: **email** (the existing confirm-code) and
+    **Telegram via the Login Widget** (the web sign-in). New `internal/accountmerge`
+    (the single-transaction data merge) and `internal/link` (the orchestrator over
+    account + accountmerge + session).
+  - **Tombstone, not delete** (interview): the secondary row is kept so a **shared
+    finished game**'s no-cascade `game_players`/`chat`/`complaints` foreign keys stay
+    valid; its seat in such a game is left in place. The merge is **refused**
+    (`ErrActiveGameConflict`) only when the two share an **active** game.
+  - **Merge algorithm** (one tx): stats summed (wins/losses/draws) + max kept;
+    `hint_balance` summed; identities repointed; non-shared `game_players` transferred
+    (shared kept); `chat_messages`/`complaints` reassigned; friendships/blocks repointed
+    with self-edge drop and dedupe (friendships by status precedence
+    accepted>pending>declined); invitations: secondary's as inviter deleted, invitee
+    rows deduped; secondary's `email_confirmations`/`friend_codes` dropped; secondary
+    tombstoned. Sessions are handled one layer up: `session.Service.RevokeAllForAccount`
+    (+ `Cache.RemoveByAccount`) retires the secondary's sessions after the tx.
+  - **Primary direction + guest inversion** (interview): primary = the current account,
+    **except** when the initiator is a **guest** and the linked identity already has a
+    **durable** owner — then the **durable account wins**, the guest's active games
+    transfer into it, the guest is retired, and a **fresh session for the durable
+    account is minted and returned** (the client adopts it). Binding a **free** identity
+    to a guest is a plain upgrade (clear `is_guest`, same session). Discharges Stage 8's
+    "guest email-binding is Stage 11".
+  - **API/UX = dedicated ops; reveal only after the code** (interview): new edge ops
+    `link.email.request/confirm/merge` (Email-rate-limited) and
+    `link.telegram.confirm/merge`. `request` **always** mails a code (no pre-send
+    "taken" signal, so a probe cannot enumerate registered addresses); a required merge
+    is revealed **only after** the code is verified, gating an explicit irreversible
+    merge step (the Profile screen's confirmation dialog). This **supersedes Stage 8's**
+    `email.bind.*` ops (and their fbs `EmailBindRequest`/`EmailConfirmRequest` tables),
+    which were retired from the gateway/UI for that reason; the backend
+    `EmailService.RequestCode`/`ConfirmCode` primitives stay (still covered by inttest).
+  - **Field policy** (interview): `display_name` = primary's; profile prefs/flags
+    (language, timezone, away window, block toggles, `notifications_in_app_only`) =
+    primary's; `hint_balance` = **sum**. A new service column **`paid_account`**
+    (`bool`, default false; lifetime one-time-payment marker, no purchase flow yet) is
+    added in `00009` and **ORed** on merge (`true` always wins). It is not user-editable
+    and is shown read-only on the admin account-detail page.
+  - **Telegram Login Widget** (interview, owner chose the broader scope): the connector
+    validates it (`internal/loginwidget`, secret = `SHA-256(bot_token)`, distinct from
+    initData) via a new `Telegram.ValidateLoginWidget` RPC; the gateway validates the
+    widget payload and passes the **trusted** `external_id` to the backend link route
+    (same trust model as `auth.telegram`). The UI offers "Link Telegram" only in a plain
+    web context (`loginWidgetAvailable`), driving the popup `Telegram.Login.auth`; it is
+    **inert in production until BotFather `/setdomain`** registers the site domain and
+    `VITE_TELEGRAM_BOT_ID` is configured (a deploy concern, Stage 12). e2e mocks the
+    widget (telegram.org is blocked on CI).
+  - **Wire/CI**: new fbs `LinkEmailRequest`/`LinkEmailConfirm`/`LinkTelegramRequest`/
+    `LinkResult` (committed Go + TS); new proto RPC (committed Go); new REST routes under
+    `/api/v1/user/link/*`. The Go workflows already span `./backend/... ./gateway/...
+    ./pkg/... ./platform/telegram/...`; integration stays `./backend/...`. UI ~90 KB gzip
+    JS (budget 100 KB). New error code `merge_active_game_conflict`.
+
 ## Deferred TODOs (cross-stage)
 
 - **TODO-1 — publish & version the solver.** Once `scrabble-solver` is stable,