docs: record the org lead's answers on report/block/hide and demo identities

- USER_SAFETY.md: section 5 becomes decisions S6-S10 (an account to report,
  game-identity blocks allowed, staff cannot be blocked, a block only hides,
  staff see hidden chat marked).
- DEMO_MODE.md: DM33-DM35 (visibly fake 1234567890-prefixed Steam and
  Discord ids plus the org lead's own Steam id; Rust-themed invented names).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

website/DEMO_MODE.md

@@ -499,6 +499,7 @@ down.
 | 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) |
 | DM32 | (2026-10-29) The moderator tour shows empty queues, and other surfaces are empty too (§11). Which get seeded? | **All four of §11's groups:** moderation history, Teams with their forum and reports, event history with the calendar, and Rust player stats |
+| DM33-DM35 | (2026-10-29) Which Steam IDs, Discord IDs and names do the invented players use? | **Visibly fake IDs** starting `1234567890` (plus the org lead's own Steam ID), and **Rust-themed invented names** (§11.3) |
 
 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
@@ -703,16 +704,23 @@ new baseline with a new map still works.
   wipe, an earlier wipe for the Wipes tab, and a day of feed lines (kills, joins, chat), so the
   leaderboard, profiles and feed are populated. The online list stays honest at zero.
 
-### 11.3 Open questions
+### 11.3 Identities (DM33-DM35, org lead, 2026-10-29)
 
-1. **Stand-in Steam IDs.** Every 17-digit `7656119…` number can belong to a real person, and these
+- **DM33, Steam IDs: visibly fake, plus the org lead's own.** Every real individual Steam ID starts
-   would appear on public leaderboards. *Recommended:* check each candidate against Steam's public
+  `7656119`, so an invented one in that range could belong to a stranger and would appear on public
-   profile page before using it, keep only IDs with no profile, and list them in the fixture with
+  leaderboards. The invented players use IDs that are visibly not Steam IDs, which start
-   that check recorded. `demo-player`'s existing stand-in gets the same check.
+  `1234567890`: `12345678900000001`, `…02`, and so on. They are 17 digits because Module-Rust checks
-2. **Invented Discord IDs.** The moderation pages show Discord user ids. *Recommended:* synthetic
+  that length on links, profiles and event steps (`links.model.js`, `eventWorld.js`), and a shorter
-   ids from a block well below any issued since 2016, named in the fixture as demo data. Nothing on
+  one would break those pages. `demoSeed.js` currently insists on `7656119…` for links and is
-   the demo links them to Discord.
+  widened for these. The one real Steam ID on the demo is the org lead's own (`76561198038695917`).
-3. **Names.** *Recommended:* invented gamer tags ("Rusty_Pete", "Scrap Baron", …), never a real
+  **To confirm:** it replaces `demo-player`'s stand-in link (`76561199910000001`, which could
-   person's name, and nothing offensive even in the seeded filter hits, which show a placeholder
+  belong to anyone).
-   word.
+- **DM34, Discord IDs: the same rule.** The invented moderation history uses visibly fake ids
+  starting `1234567890`, padded to a snowflake's 18 digits. The org lead did not answer this one
+  separately; it follows DM33 and is flagged on the PR.
+- **DM35, names: Rust-themed and invented.** Fun gamer tags from the game's world, such as
+  "Rusty_Pete", "Scrap Baron", "Naked_On_The_Beach", "Rock Enthusiast", "Big Oil Bandit", "TC
+  Thief", "Hazmat Hank" and "Bean Can Dan", and clans such as "The Scrap Collective" and
+  "Outpost Loiterers". Never a real person's name, and nothing offensive: the seeded filter hits
+  show a placeholder word.
 

website/USER_SAFETY.md

@@ -15,7 +15,7 @@ true rather than retake the questionnaire (S1).
 |---|---|---|---|
 | **Report** | any signed-in member | a chat line (web + app), a forum thread, post or upload (web; app later, §6) | a row in the existing **Reports** queue (`TEAMS.md` §5.6). Changes nothing on its own |
 | **Hide for me** | any signed-in member | the same items | that one item disappears from **their own** view, on every device. No report is filed |
-| **Block** | any signed-in member | the author of any of those items | everything that author writes (chat lines and forum content) disappears from the blocker's view, on the website and in the app, on every device. Undone from *Account → Blocked* |
+| **Block** | any signed-in member | the author of any of those items, unless the author is staff (S8) | everything that author writes (chat lines and forum content) disappears from the blocker's view, on the website and in the app, on every device. Undone from *Account → Blocked* |
 | **Hide for everyone** | staff (and, for their own forum, Team leaders, as today) | the Reports queue, the forum's existing moderation menu, and the item's own menu | the item disappears for everybody except staff, who see it with a *Hidden by staff* marker and can undo it |
 
 A report and a hide are separate on purpose, as `TEAMS.md` §5.6 already says: filing a report must
@@ -48,7 +48,7 @@ staff's.
   the public `GET /public/rust/servers/:id/events`. The app polls it signed out or in.
 - **No blocks or per-member hides** exist anywhere.
 
-## 4. Design (recommendations; §5 lists what needs an answer)
+## 4. Design (§5 holds the decisions that shape it)
 
 ### 4.1 Core (`website`)
 
@@ -99,23 +99,15 @@ staff's.
 - **Account → Blocked** lists blocks and undoes them, mirroring the web page.
 - The feed filters with the member's lists, as in §4.1.
 
-## 5. Questions for the org lead
+## 5. Further decisions (org lead, 2026-10-29)
 
-Each has a recommendation; nothing is built until they are answered.
+| # | Question | Answer |
-
+|---|---|---|
-1. **Signed out.** Can a signed-out visitor report a chat line? *Recommended: no.* Reporting, hiding
+| S6 | Can a signed-out visitor report a chat line? | **No.** Reporting, hiding and blocking all need an account, as forum reports do today, so the queue is not open to anyone with `curl`. A signed-out viewer sees *Sign in to report or block* |
-   and blocking all need an account, as forum reports do today. Otherwise the queue is open to
+| S7 | Can a member block a game identity (a Steam ID) that is linked to no account? | **Yes** (§4.1's game block). Almost everyone in a Rust chat feed is unlinked |
-   anyone with `curl`. Play needs the mechanism to exist, not to be anonymous.
+| S8 | Can a member block staff? | **No.** The block is refused when its target is a staff account (admin, editor or moderator), or a game identity linked to one, and the menu does not offer it on staff content. A game block whose identity later links to a staff account stops applying, and *Account → Blocked* says why. *Hide for me* still works on a single staff item |
-2. **Blocking someone who has no account.** Can a member block a Steam ID that is linked to nobody?
+| S9 | What does a block do to the blocked person? | **Nothing beyond hiding** their content from the blocker. They are not told; there are no direct messages to stop |
-   *Recommended: yes* (§4.1's game block). Almost everyone in a Rust chat feed is unlinked.
+| S10 | Do staff still see a chat line hidden for everyone? | **Yes, marked** *Hidden by staff*, so the hide can be checked and undone, as the forum already treats its own hidden posts |
-3. **Blocking staff.** Can a member block a moderator or admin? *Recommended: yes.* A block only
-   hides content from the blocker. It changes nothing about staff powers, and it doesn't stop staff
-   seeing the blocker.
-4. **What a block does to the blocked person.** Nothing beyond hiding, *recommended*. There are no
-   direct messages to stop, and telling someone they were blocked invites the harassment the block
-   was for.
-5. **Staff view of hidden chat.** Do staff still see a line hidden for everyone? *Recommended: yes,
-   marked*, so a hide can be checked and undone, as the forum already treats its own hidden posts.
 
 ## 6. The team forum in the app (planned, not scheduled)
 
@@ -126,7 +118,7 @@ Play declarations gain "user-generated content: collected". M21 says so.
 
 ## 7. Build order
 
-1. **This plan** (docs). Answers to §5 recorded here.
+1. **This plan** (docs), with §5's answers.
 2. **Core** (`website`): §4.1, `MODULE_API` 1.20.0, tests, OpenAPI, `BACKEND_DESIGN.md`,
    `MODULE_API.md`, `TEAMS.md` §5.6 amended. One PR.
 3. **Module-Rust** (`edge`): §4.2 plus the core-ref pin. One PR. **Integration-kit**: the re-pin and