docs(ui): finalize MVP plan structure and de-archaeologize topic docs

MVP web client (Phases 1-30) is complete; reorganize planning + living docs around that.

- PLAN.md kept as the staged MVP record (1-30) with a status block + pointers; removed the 31-36 stages, regression scenarios, and deferred-TODO section (moved out); fixed a stale cross-machine plan path.

- ui/PLAN-finalize.md (new): active web-finalization plan in 8 stages (visual system, a11y, i18n, error UX, PWA, build hygiene, docs, owner manual-QA loop); absorbs former Phases 33 and 35.

- ui/ROADMAP.md (new): post-MVP (Wails, Capacitor, realistic projection, acceptance + regression scenarios) and triaged deferred follow-ups.

- ui/docs/README.md (new): grouped topic-doc index.

- De-archaeologized all 20 ui/docs topic docs + ui/README.md + ui/core/README.md: stripped Phase-N build history, rewritten as current-state; deferred work now points at ROADMAP.md / PLAN-finalize.md. Docs-only; no code change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

ui/docs/lobby.md

@@ -2,11 +2,9 @@
 
 The lobby is the first authenticated view; the user lands here after
 the email-code login completes (see
-[`docs/auth-flow.md`](auth-flow.md)). Phase 8 introduced the live
-lobby with five sections, the create-game form, and the TS-side
-FlatBuffers integration the rest of the client builds on. This doc
-captures the sections, the application / invite lifecycle the user
-sees, and the defaults baked into the create-game form.
+[`docs/auth-flow.md`](auth-flow.md)). This doc captures the
+sections, the application / invite lifecycle the user sees, and
+the defaults baked into the create-game form.
 
 ## Sections
 
@@ -23,15 +21,15 @@ width.
 | `my applications`    | `no applications`     | `lobby.my.applications.list` | Status badge (`pending` / `approved` / `rejected`)      |
 | `public games`       | `no public games`     | `lobby.public.games.list`  | Submit application via inline race-name form (`lobby.application.submit`) |
 
-The header preserves the device-session-id `<code>` block from the
-Phase 7 placeholder (kept as a debug affordance) plus a greeting if
-the gateway returns a `display_name` for the caller.
+The header preserves the device-session-id `<code>` block (kept as
+a debug affordance) plus a greeting if the gateway returns a
+`display_name` for the caller.
 
-`GameSummary` carries an extra `current_turn` field (Phase 11
-extension) that the lobby UI does not display directly — the in-game
-shell reads it from the same payload to load the matching
-`user.games.report` for the map view without an additional gateway
-call. See [`game-state.md`](game-state.md) for the consumer's view.
+`GameSummary` carries a `current_turn` field that the lobby UI does
+not display directly — the in-game shell reads it from the same
+payload to load the matching `user.games.report` for the map view
+without an additional gateway call. See
+[`game-state.md`](game-state.md) for the consumer's view.
 
 ## Application lifecycle
 
@@ -104,7 +102,7 @@ and falls back to the gateway-supplied message via
 
 The gateway encodes lobby payloads through `pkg/transcoder/lobby.go`
 into FlatBuffers bytes; the browser must decode them with the same
-schema. Phase 8 ships:
+schema. The TS integration ships:
 
 - `flatbuffers` runtime dependency in `ui/frontend/package.json`;
 - `make -C ui fbs-ts` driving `flatc --ts` to regenerate the bindings
@@ -112,8 +110,6 @@ schema. Phase 8 ships:
 - a Vitest round-trip suite (`tests/lobby-fbs.test.ts`) that catches
   binding drift in CI.
 
-Phase 7's `user.account.get` decode previously used
-`JSON.parse(TextDecoder)`; that path was rewritten in Phase 8 to use
-the same generated `AccountResponse` table, so the lobby greeting now
-works against a real local stack as well as the mocked Playwright
-fixtures.
+`user.account.get` decodes through the generated `AccountResponse`
+table, so the lobby greeting works against a real local stack as well
+as the mocked Playwright fixtures.