chore(facts): protocol 5 and Module API 1.9.0 -- HOLD until the cutover

Engagement Phase 12b. **This branch is deliberately red and must not be merged until the
Phase 13 cutover has landed link and servuo-plugins on `main` and CI has republished the
bundle.** checkFacts.mjs fetches every value from the source repo's `main`, so it fails
today exactly as designed:

  FAIL  protocol (sidecar)   platform.json 5   link main 4
  FAIL  protocol (overlay)   platform.json 5   servuo-plugins main 4
  FAIL  moduleApi            platform.json 1.9.0   website main 1.6.0
  FAIL  protocol (bundle)    platform.json 5   installer bundles:current.json 4

Every other check is green on this branch: checkLinks 2503, checkReference 22, checkA11y,
checkCsp, checkSidebar, 42 tests.

moduleApi is **1.9.0**, not the 1.7.0 the plan named -- Phase 11 moved it twice after that
sentence was written (1.8.0 for the `admin` ceiling, 1.9.0 for the module seed API).

## Also: the one page whose whole subject is the protocol number was the one page that
## hardcoded it

platform.json's own header says no version number is ever hardcoded in prose, and
`architecture/protocol-versions.mdx` had `4` written out three times -- the headline
sentence and both declaration-site rows. It now imports platform.json like every other
page that quotes a fact, so it moves with the JSON and cannot say 4 while the JSON says 5.

Note the interpolation is OUTSIDE the code spans: MDX does not evaluate an expression
inside backticks, so `PROTOCOL_VERSION: u32 = {platform.protocol}` would have rendered the
braces literally. Verified in the built HTML -- "currently 5", and no `platform.protocol`
survives anywhere in the output.

The same page's "what a bump obliges" section said version 4 was the first bump to need a
store migration, which read as though every bump does. v5 needed none (it only widens
frames the store already keeps whole -- docs link/v5.md), so the sentence now says which
did and which did not, and v5.md joins v4.md under canonical documents.

## The fill-in step, at merge time

Three values are not knowable today because the artefact does not exist yet. After the
bundle republishes, run:

    GITEA_TOKEN=<token> node scripts/checkFacts.mjs

and copy what it prints in the "says" column into src/data/platform.json:

  * bundle.tag, bundle.sidecar, bundle.overlay -- from installer bundles:current.json
  * releases.Module-uo -- if the cutover cuts a new module release
  * verifiedOn -- the date you ran it

Then re-read `getting-started/connect-a-game-server` and `administration/the-shard-connection`,
which quote the bundle, before merging. The check is green when all 19 agree.

AI-assisted: written with Claude Code.

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

src/content/docs/docs/architecture/protocol-versions.mdx

@@ -4,12 +4,13 @@ description: One number, declared in three repositories, that decides whether a
 ---
 
 import { Aside } from '@astrojs/starlight/components';
+import platform from '../../../../data/platform.json';
 
 The loopback wire protocol between the game plugin and the sidecar is a **versioned
 compatibility contract**, not a build dependency. Nothing compiles the three sides together,
 so the number is what stops a mismatch from being discovered as corrupted data.
 
-The current protocol is **4**.
+The current protocol is **{platform.protocol}**.
 
 ## Three declaration sites
 
@@ -17,8 +18,8 @@ The same number is written down in three places, and they must move together.
 
 | Where | What declares it |
 |---|---|
-| `link/sidecar/src/main.rs` | `pub const PROTOCOL_VERSION: u32 = 4` — what the sidecar speaks |
+| `link/sidecar/src/main.rs` | `PROTOCOL_VERSION`, currently {platform.protocol} — what the sidecar speaks |
-| `servuo-plugins/overlay.toml` | `protocol = 4` — what the plugin overlay speaks |
+| `servuo-plugins/overlay.toml` | `protocol`, currently {platform.protocol} — what the plugin overlay speaks |
 | The bundle manifest | Copied from `overlay.toml` by CI, so a released pair carries its own claim |
 
 <Aside type="caution" title="Bump the overlay in the same PR as the emitters">
@@ -44,19 +45,19 @@ allowed to be chosen independently.
 
 ## What a bump obliges
 
-Changing a message shape means editing every side plus the specification. A protocol-4
+Changing a message shape means editing every side plus the specification. The most recent
-change touched:
+bump touched:
 
 | Repository | What had to change |
 |---|---|
 | `servuo-plugins` | The emitters, the config keys, and `overlay.toml` |
-| `link` | `PROTOCOL_VERSION`, a store migration, and the projections |
+| `link` | `PROTOCOL_VERSION`, and the projections |
 | `module-uo` | The tables, the ingest, and the kind-to-feature map |
 | `docs` | The protocol document and the integration guide |
 
-Note `link`'s entry: **a protocol bump can require a store migration**, because the sidecar
+**A protocol bump can also require a store migration**, because the sidecar persists what it
-persists what it forwards. That is not automatic, and version 4 was the first bump that
+forwards. That is not automatic — version 4 needed one and version 5 did not, because
-needed one.
+version 5 only widened frames the store already keeps whole.
 
 ## This is not the module API version
 
@@ -92,8 +93,10 @@ What is worth inheriting is the **shape**:
 
 ## Canonical documents
 
+[`link/v5.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/link/v5.md)
+is the current protocol's record, including its cross-repository obligations, and
 [`link/v4.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/link/v4.md)
-is the protocol-4 record, including its cross-repository obligations;
+the one before it;
 [`link/PLAN.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/link/PLAN.md)
 §7 is the wire protocol, and
 [`link/INTEGRATION.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/link/INTEGRATION.md)

src/data/platform.json

@@ -14,9 +14,9 @@
 
   "verifiedOn": "2026-08-19",
 
-  "protocol": 4,
+  "protocol": 5,
 
-  "moduleApi": "1.6.0",
+  "moduleApi": "1.9.0",
 
   "bundle": {
     "tag": "2026.08.19",