Stage 7 (wip): docs bake + stage renumber (insert UI Stage 8, shift +1)

- PLAN.md: new Stage 8 (UI social/account/history); Telegram->9, Admin->10, Linking->11, Polish->12; tracker + Stage 7 refinements; split the Stage 6 'wired in Stage 7' note between 7 and 8
- ARCHITECTURE: promote ui to current (slice scope, board-replay, codegen, theming, mock)
- FUNCTIONAL(+ru): client-app section with the Stage 7/8 split
- README + ui/README + CLAUDE.md: UI build/run/test, codegen, pnpm notes
- bumped Stage 8-11 refs (+1) across docs and code comments

docs/ARCHITECTURE.md

@@ -24,9 +24,20 @@ Three executables plus per-platform side-services:
   administration. Embeds the **`scrabble-solver`** engine **as a library,
   in-process** — there is no per-game container. The only network consumer of
   `backend` is `gateway` (plus platform side-services over an internal API).
-- **`ui`** *(planned)* — pure-HTML5 client (plain Svelte + Vite, static build).
-  Talks to `backend` only through `gateway`. Embeddable in platform webviews;
-  packageable to native (iOS/Android) via Capacitor.
+- **`ui`** — pure-HTML5 client (plain Svelte 5 + TypeScript + Vite, static build;
+  no SvelteKit). Talks to `backend` only through `gateway` over Connect-RPC +
+  FlatBuffers, with the edge TS bindings generated from the **same** `edge.proto`
+  and `scrabble.fbs` and committed under `ui/src/gen/`. The **playable slice**
+  (Stage 7) covers auth, "my games", auto-match, the board (play/pass/exchange/
+  resign), hint, word-check, chat/nudge, the live stream, i18n (en/ru) and a profile
+  view; the social/account/history surfaces follow in Stage 8. There is no board on
+  the wire — the client **reconstructs the 15×15 board by replaying the move
+  journal** (§9.1) and renders board, tiles, premium squares and effects as pure
+  CSS + Unicode (no image/font/SVG assets). Tiles are placed by Pointer-Events drag
+  or tap; a CSS-token theme is light/dark and Telegram-themeParams-ready; navigation
+  is a hash router and the session token is held in memory + IndexedDB. A build-flagged
+  in-memory mock transport (`pnpm start`) runs the whole slice with no backend.
+  Embeddable in platform webviews; packageable to native (iOS/Android) via Capacitor.
 - **`platform/<name>`** *(planned)* — per-platform side-services (Telegram bot
   first): deep-link invites and platform-native push notifications. They talk
   to `backend` over an internal API.
@@ -108,7 +119,7 @@ arrive from a platform rather than completing a mandatory registration).
   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
+  refused — adopting it would be a merge, which Stage 11 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
@@ -140,7 +151,7 @@ Key points:
   word-check tool through `Registry.Lookup`.
 - **Dictionary versioning — pin per game.** A game records the `dict_version` it
   started on and finishes on that version; new games use the latest. Multiple
-  versions may be resident at once. An admin reload *(planned, Stage 9)*
+  versions may be resident at once. An admin reload *(planned, Stage 10)*
   registers a new version through `Registry.Load`; delivery is the DAWG file in
   the image / a volume mounted at the dictionary directory. (A future split of
   the solver into engine + dictionary generator with versioned artifacts is
@@ -202,7 +213,7 @@ Key points:
 - **Word-check tool**: unlimited dictionary lookups against the game's pinned
   dictionary; each result offers a **complaint** (complainant, game, variant,
   dict_version, word, the disputed result, an optional note) that lands in an
-  admin review queue *(admin side planned, Stage 9)*.
+  admin review queue *(admin side planned, Stage 10)*.
 
 ## 7. Robot opponent
 
@@ -250,7 +261,7 @@ requires (there is no DM surface; chat is per-game).
   emits a **match-found** notification (§10), delivered over the live stream;
   `Poll` remains as a fallback for a client that is not currently streaming.
 - **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
+  friend list or internal ID now, by platform deep-link with Stage 9. Declining or
   cancelling removes the pending request; blocking someone severs an existing
   friendship.
 - **Block**: two independent **global** account toggles (`block_chat`,
@@ -275,7 +286,7 @@ requires (there is no DM surface; chat is per-game).
   (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.
+  are Stage 11.
 
 ## 9. Persistence
 
@@ -337,7 +348,7 @@ does not cover.
 ## 10. Notifications
 
 Two channels: the **in-app live stream** (delivered from Stage 6) and
-**platform-native push** (out-of-app, via the platform side-service — Stage 8).
+**platform-native push** (out-of-app, via the platform side-service — Stage 9).
 The backend emits notification intents through an in-process hub
 (`internal/notify`, a `Publisher` seam installed on the game, social and lobby
 services); a single backend→gateway **gRPC server-stream** (`Push.Subscribe`,
@@ -348,7 +359,7 @@ robot-driver and timeout-sweeper moves emit too), **chat-message** and **nudge**
 (from the social service), and **match-found** (from the matchmaker, §8). Event
 payloads are FlatBuffers-encoded by the backend and forwarded verbatim. A client
 that is not currently streaming falls back to the matchmaker's `Poll` for
-match-found. Out-of-app platform push (your-turn, nudge) is wired in Stage 8;
+match-found. Out-of-app platform push (your-turn, nudge) is wired in Stage 9;
 session-revocation events and cursor-based stream resume are deferred
 (single-instance MVP).