feat(facts): phase 13 - per-game facts, Rust and RunicNPC checked, main green again

platform.json drops the single protocol/bundle/capability list for a
`games` object (uo, rust) plus a `runicnpc` block. checkFacts.mjs loops
the protocol, plugin-protocol, capability and bundle checks over both
games, reads the schema-2 bundles at v2/<game>/current.json, checks each
module's coreApi, and reads RunicNPC's plugin.toml. 41 facts, up from 19;
clears the two that were red on main (Module API 1.17.0, installer
v0.8.0).

D66: the hero, footer and structured data show the Module API only; each
game's protocol and bundle go on that game's pages, and the docs landing
table splits into shared versions plus one column per game.

The re-read section 1 requires found, and this fixes:
- three hard-coded "1.6.0" Module API versions in the module docs
- module-lifecycle saying modules load alphabetically (the loader now
  refuses a second module, W19), and the install pages never mentioning
  the one-module rule
- "there is one module" in five places, now two modules both built
  inside this project; the Integration Kit keeps its draft banner
- the homepage diagram's ServUO/uo-link sub-labels (D63 wording now)

notBuilt drops `second-module` (resolved by Module-Rust's release) and
rewords `multi-module`.

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

src/data/notBuilt.mjs

@@ -78,26 +78,18 @@ export const notBuilt = [
     scope: ['features', 'integrations', 'modules'],
     title: 'More than one game module at a time',
     body:
-      'One active module per deployment. The database columns that would scope data to a ' +
-      'module exist and are populated, so the door is not nailed shut, but nothing ' +
-      'exercises them and no interface offers it. A community running two games runs two ' +
-      'deployments.',
+      'One module per deployment, and the site enforces it: it loads one module at boot ' +
+      'and refuses every other, with a message saying so, rather than letting two games ' +
+      'share one site. The database columns that would scope data to a module exist and ' +
+      'are populated, so the door is not nailed shut, but no interface offers it. A ' +
+      'community running two games runs two deployments.',
     resolvedBy:
       'Someone needing it. The schema was shaped to keep it possible, which is a different ' +
       'thing from planning it.',
   },
-  {
-    id: 'second-module',
-    scope: ['integrations', 'modules'],
-    title: 'A second game module',
-    body:
-      'There is exactly one, and it is Ultima Online. A paper dry-run for a Rust module ' +
-      'exists and is deliberately unimplemented — it was written to test whether the ' +
-      'module contract generalises, not to ship. Until a second one exists, "any game" is ' +
-      'an argument about a shape rather than a demonstration.',
-    resolvedBy: 'The first module built for a game that is not Ultima Online.',
-    link: { href: `${GITEA}/docs/src/branch/main/modules/rust-dryrun.md`, label: 'The dry-run' },
-  },
+  // `second-module` was here until phase 13 (PLAN.md §16): "a second game module", resolved
+  // by exactly the event its own `resolvedBy` named — the Rust module's release. Removed
+  // rather than reworded, because an absence that is no longer absent is not an entry.
   {
     id: 'integration-kit-draft',
     scope: ['integrations', 'modules'],