Merge pull request 'docs(website): record the demo's step 6 site side and Play state (DM30, DM31)' (#389) from docs/demo-step6 into main

Reviewed-on: #389

website/DEMO_MODE.md

@@ -1,8 +1,9 @@
 # Demo mode — `demo.runicgateway.com`
 
 **Status:** design **fully decided** 2026-10-23 (DM1-DM18, §9). §10 step 1 (core, `MODULE_API`
-1.18.0) is **built**, and so is step 2 (the module, with its core hook `MODULE_API` 1.19.0, DM18);
-steps 3-6 are not.
+1.18.0) is **built**, and so are steps 2-5 (the module with its core hook `MODULE_API` 1.19.0, the
+kit, the app, and the deployment, live since 2026-10-27). Step 6 is **built on the site side**
+(2026-10-28) and waits on the Play Console.
 **Issue:** `RunicGateway/website#222`. **Why now:** Google Play (`../android/PLAN.md` item 9,
 M8) needs a public HTTPS site with working sign-ins for its reviewers and for the 12 testers who
 must be opted in for 14 days before the app can apply for production.
@@ -495,6 +496,8 @@ down.
 | DM27 | (step-5 walk, W4, 2026-10-28) `demo-player` can remove its stand-in Steam link, and staff can remove it from Admin → Users. Lock it, or leave it to the wipe? | **Lock it, both ways.** The player's route through `demoLocks`; the staff route in its handler, because it serves under core's users mount (§3.3). Module-Rust patch release |
 | DM28 | (step-5 walk, W1, 2026-10-28) The seeded events' actions start switched off on a fresh database, so they fail when run. Fix? | **Yes.** `seed:demo` switches on every action a seeded event uses, uncapped, with the events (§7.3). Core only, no `MODULE_API` change |
 | DM29 | (step-5 walk, W2, 2026-10-28) `SECRET_WORDS` also hides harmless fields such as "Allow Master Key" and "TC Auth Only". Narrow it? | **No, leave it as is** |
+| DM30 | (step 6, 2026-10-28) How does runicgateway.com `/beta` publish the logins? | **Live from the demo.** `/beta` reads this site's `GET /public/settings` `demo.logins` on its server, caches it for a minute, and links to `/account/login` when the demo does not answer (runicgateway.com D82) |
+| DM31 | (step 6) runicgateway.com's "See it running" links were UO routes, which 404 here. What do they do? | **Per game.** A deep link names its game, and that site's mounted `demoGames` (`["rust"]` for this demo) says which games' links show. Rust's point at `/rust` and `/rust/servers/demo?tab=…`, so that site now quotes the fixture's server id `demo` (runicgateway.com D83) |
 
 DNS and HTTPS for `demo.runicgateway.com` come from an external reverse proxy, which the org lead is
 setting up. The app sits behind it on plain HTTP; core already trusts one proxy hop for
@@ -630,4 +633,17 @@ through that proxy.
    - **Steam link, W4.** `demo-player`'s unlink and staff's unlink both answer `403 DEMO_LOCKED`, and
      the link stays.
 6. **Play**: the sign-in details in the Play Console point at `play-review`;
-   runicgateway.com `/beta` publishes the logins.
+   runicgateway.com `/beta` publishes the logins. **Site side built 2026-10-28** in
+   `runicgateway.com` (DM30, DM31). `/beta` lists the published logins and the next wipe as this site
+   serves them, marks its "somewhere to point it" gate in place, and names the host to type into the
+   app. The homepage, `/features/` and `/modules/rust/` link into the demo, and UO's links stay
+   hidden. Against the live demo: three logins listed (`play-review` not among them), the 22:00 UTC
+   wipe shown, seven Rust links and three core links filled, and `/uo/guilds` left empty. **It goes
+   live** when that site's mounted `brand.json` gains `"demoUrl": "https://demo.runicgateway.com"` and
+   `"demoGames": ["rust"]` and its container restarts.
+   **Play Console:** the *Sign in details* declaration (formerly *App access*) is filled in but not
+   saved: *Yes, restricted*, the name *Admin account (demo site)*, the username `play-review`, and
+   instructions (enter `demo.runicgateway.com` on the first screen, the two-hour reset, the refused
+   locks). The org lead types the password, ticks the full-access attestation and saves. The closed
+   track does not exist yet (Test and release shows *Get started* for closed and internal testing), so
+   there is no opt-in URL for `betaOptInUrl`, and `/beta`'s first gate stays shut.