docs(website): record slice 3, and MODULE_API 1.3.0

The client half's move: 35 files / 5,332 lines (the table said 51 / ~3,700 and
is corrected, not re-derived to match). The seven-kit-members-plus-format claim
held exactly, so the kit needed no additions.

Contract, 1.2.0 -> 1.3.0, all additive: `icon` on a nav item, a third slot
`player.invite.accepted`, and `api.BASE` — which §3.5 specified from the first
draft and shared.js had never published, because nothing needed it until a
module had to build an EventSource URL.

§2.3's narrowing note said game-signup policy was core's business. It was wrong
in both directions: the setting's help text names Bridge.cfg, and slice 1 had
shipped a controller calling a function the narrowing does not expose, so
POST /player/shard/account answered 500 for every caller until this slice.

§3.7 gains the rule the invite slot needed: core may ask whether a slot is
filled when the answer changes CONTROL FLOW, never when it changes decoration.
Decoration goes inside `<Slot wrap>` — that is the footer-separator bug.

§7.7 gains what running it against the real module found, rather than a
throwaway: the unguarded portal icon, the relative-MODULES_DIR trap, and the two
operational notes (a module needs its own npm ci; copy the directory, never
symlink it).

Also recorded: the nav-override cost is worse than "a hidden row may reappear" —
the review instance had the nine UO rows gathered into a dropdown section, and
the whole section is lost. And `api-route-inventory.json` was a slice stale at
228 routes; refreshed to the 158 core actually serves.

Co-Authored-By: Claude <noreply@anthropic.com>

android/PLAN.md

@@ -85,7 +85,7 @@ change/set password (the SSO-account "no current password" path from `has_passwo
 list/unlink SSO identities — each mutation folding its `ApiResult` into a section-scoped, localized
 banner (§7). **Game-account linking** (§6.3) — the in-game `[link` one-time code (`POST
 /player/shard/link`) plus the hybrid signup (`POST /player/shard/account`, shown only when the public
-`gameAccountSignup` flag is set), and the linked-accounts list. **Own game data**, text-only (§6.3):
+`gameAccountSignup` flag is set — see the OWED note below), and the linked-accounts list. **Own game data**, text-only (§6.3):
 per-account character roster → a character sheet (attributes, vitals, resistances, best-first skills,
 equipment with AOS mods, and guild/governor standing chips — bare cliloc-number titles/item names are
 skipped, as the app ships no cliloc table, matching the website's `CharacterSheet.jsx`); player
@@ -99,6 +99,18 @@ spec-aligned (as recorded for M1); 17 new JVM unit tests cover the account + pla
 **No backend/API change** — the `/auth/me/*` and `/player/shard/*` surfaces the app consumes were the
 §8 prerequisites, already landed.
 
+> **OWED — `gameAccountSignup` moved and the app has not followed (2026-08-11).** Phase 3 slice 3 of
+> the website's module extraction (`docs/website/MODULE_SYSTEM.md` §2.7.1) moved game-account signup
+> policy out of core: the flag is no longer on `GET /public/settings` and is now on module-uo's
+> `GET /public/shard/features`, beside the visibility flags. `PublicDto.kt:80` defaults it to
+> `false`, so **nothing crashes** — `CharactersViewModel.kt:72` reads `false` and the app simply
+> stops offering game-account creation. The fix is one DTO field, one ViewModel line and two tests,
+> reading the flag from the features endpoint the app already calls.
+>
+> Deferred rather than coordinated into the slice (org lead, 2026-08-11): the website work lands on
+> `edge` and reaches `main` as one cutover, so there is room. **It must land before that cutover** —
+> after it, a shipped app quietly loses a feature.
+
 ✅ **M5 — design pass** (2026-07-20, `RunicGateway/Android-app#10`): the shard-website theme applied
 across every screen, restyling the working M1–M4 UI with **no architecture, data-flow, endpoint, or DTO
 change** (§2.1). The design was produced in Claude Design (`Runic Gateway Screens.dc.html`) and