feat(docs): phase 14 - game-neutral core docs, an Ultima Online group, and checkTerms

PLAN.md §16, D63/D64, plus D67-D69 taken 2026-10-22.

- Core docs use core's words: a Team, a game server, the sidecar, the bridge
  plugin, the game module. Detail that belonged to Ultima Online moved into
  its pages rather than being dropped.
- New "Ultima Online" sidebar group (nine pages): an overview, Connect a
  ServUO shard, Verify the bridge, The shard connection, Client files,
  Troubleshooting, Bridge.cfg, sidecar.toml, Shard event catalog. Five moved
  URLs answer a real 301 (src/config/redirects.mjs, asserted by the served
  test).
- Getting started is game-neutral. "Connect your game server" keeps the old
  URL and hands off to each game; Rust links docs main:rust-link/INSTALL.md
  until phase 15. "Verify the whole stack" stays, neutral (D69).
- D68: GameExample.astro labels a game's real example on a core page with the
  game's name; checkTerms allows that game's words inside it.
- scripts/checkTerms.mjs, the twelfth check: 16 game words, docs pages and
  both sidebar trees, one allowlisted phrase (Discord's "Guild (server) ID").
  Wired into verify and pr-checks.yml.
- canonicalDocs grouped by game; the Rust group carries four documents.
- D67: the screenshot rule from #32 is adopted.

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

src/data/reference.mjs

@@ -84,7 +84,7 @@ export const sidecarConfig = {
 
 /** `installer` — `src/cli.rs`'s `Command`. */
 export const installerCommands = {
-  Install: 'Set up the shard side: sync the overlay, install the sidecar, register its service',
+  Install: "Set up a game server's side: deploy the bridge plugin, install the sidecar, register its service",
   Doctor: 'Diagnose an existing install',
   Update: 'Move to a newer bundle',
   Uninstall: 'Remove what install put there',
@@ -238,25 +238,42 @@ export const bridgeCfg = {
  */
 export const visibilityLadder = ['anonymous', 'logged_in', 'player', 'staff', 'admin'];
 
-/** Canonical documents, by the question each answers. Checked to still exist in `docs`. */
+/**
+ * Canonical documents, by the question each answers. Checked to still exist in `docs`.
+ *
+ * Grouped by whose documents they are (PLAN.md §16, D63): `core` describes the platform in
+ * core's words, and each game's group may use that game's. The keys of the outer object are
+ * `core` plus keys of `platform.json`'s `games`, which is what lets the page label a game's
+ * group with the game's name and `checkTerms.mjs` hold each group to its own vocabulary.
+ */
 export const canonicalDocs = {
-  'website/ARCHITECTURE.md': 'How the website fits together — the canonical diagram',
-  'website/BACKEND_DESIGN.md': 'The API, schema and security contract',
-  'website/MODULE_SYSTEM.md': 'Why the module system is shaped this way',
-  'website/MODULE_API.md': 'Everything a module may do — the contract',
-  'website/TEAMS.md': 'Teams as a platform primitive',
-  'website/EVENTS.md': 'The Event System — leases, the ledger, and the module seam',
-  'website/SHARD_VISIBILITY.md': 'The audience ladder, for administrators',
-  'website/THEMING_AND_NAV.md': 'Admin-configurable theme, assets and navigation',
-  'website/TRUSTED_DEVICES_MFA.md': 'Trusted devices and the second factor',
-  'link/PLAN.md': 'The sidecar design of record, the data catalog and the wire protocol',
-  'link/INTEGRATION.md': 'Integrating with the sidecar',
-  'link/v8.md': 'The current protocol, and its cross-repository obligations',
-  'link/SHARD_PREREQS.md': 'What a shard host needs before any of this works',
-  'link/ADMIN_CONTROLS.md': 'What the site may command the game to do',
-  'installer/INSTALL.md': 'The operator guide for setting a shard up',
-  'installer/PLAN.md': "The installer's design of record",
-  'modules/rust-dryrun.md': 'The Rust module as first designed on paper, to test that the contract generalises — since built',
-  'modules/uo/API.md': "module-uo's own API, including its audience rules",
-  'android/PLAN.md': 'The Android app',
+  core: {
+    'website/ARCHITECTURE.md': 'How the website fits together — the canonical diagram',
+    'website/BACKEND_DESIGN.md': 'The API, schema and security contract',
+    'website/MODULE_SYSTEM.md': 'Why the module system is shaped this way',
+    'website/MODULE_API.md': 'Everything a module may do — the contract',
+    'website/TEAMS.md': 'Teams as a platform primitive',
+    'website/EVENTS.md': 'The Event System — leases, the ledger, and the module seam',
+    'website/THEMING_AND_NAV.md': 'Admin-configurable theme, assets and navigation',
+    'website/TRUSTED_DEVICES_MFA.md': 'Trusted devices and the second factor',
+    'installer/INSTALL.md': 'The operator guide for setting a game server up',
+    'installer/PLAN.md': "The installer's design of record",
+    'modules/rust-dryrun.md': 'The second game module as first designed on paper, to test that the contract generalises — since built',
+    'android/PLAN.md': 'The Android app',
+  },
+  uo: {
+    'link/PLAN.md': 'The sidecar design of record, the data catalog and the wire protocol',
+    'link/INTEGRATION.md': 'Integrating with the sidecar',
+    'link/v8.md': 'The current protocol, and its cross-repository obligations',
+    'link/SHARD_PREREQS.md': 'What a shard host needs before any of this works',
+    'link/ADMIN_CONTROLS.md': 'What the site may command the game to do',
+    'website/SHARD_VISIBILITY.md': 'The audience ladder, for administrators',
+    'modules/uo/API.md': "The module's own API, including its audience rules",
+  },
+  rust: {
+    'rust-link/INSTALL.md': 'Installing the Rust bridge — the installer, the Pterodactyl egg, or by hand',
+    'rust-link/INTEGRATION.md': 'Integrating with the sidecar',
+    'rust-link/PROTOCOL.md': 'The wire protocol between the bridge plugin and the sidecar',
+    'modules/rust/PLAN.md': 'The Rust module design of record',
+  },
 };