docs(site): the Event System — the platform's facts, and two pages for it

Phase 16c of the events plan: `runicgateway.com`'s half of the workstream, now
that `main` carries the engine, the module, the app and the bundle.

The checks were already red and named their own answers:

* `checkFacts` — nine values had moved. Protocol 5 → 7 in all three declaration
  sites, `moduleApi` 1.9.0 → 1.10.0, the bundle to 2026.09.10 with sidecar
  v2.2.0 and overlay v1.2.0, `link` v2.2.0, `Module-uo` v1.2.2.
* `checkReference` — twenty-seven `Bridge.cfg` keys the site listed nowhere: the
  events switch and its sweep, the ten caps, the oracle NPC, the two lease keys
  and the seven participation keys. They are five new groups rather than an
  appendix to an existing one, because `EventsEnabled` is a second consent
  switch and belongs beside its own ceilings.

Two pages, matching the treatment Teams has:

* **Scheduled events** (Administration) — where it is and who sees it, authoring
  and immutable versions, the switchboard that arrives off, caps as a condition
  on an `UPDATE` rather than a role check, the dry run, the run console, what an
  event owns versus what it borrows, generated cleanup, the shard's own switches,
  and what a player sees.
* **Events architecture** — the two sentences it turns on, what is a table and
  what deliberately is not, budgets in SQL, the ledger's two rules, at-most-once
  on a wire that can lose an answer, the three layers, and the four omissions.

And the rest of the surface:

* `/privacy` gains **`deploy-events`** — the participation ledger is personal
  data and no row named it. Scores and ranks against a module-opaque member key,
  linked to an account where one is linked; the diagnostic log swept after 90
  days on terminal runs only; the run, its steps and its participants not swept
  at all, because they are the record of what was done to a shared world.
  `deploy-game-data`'s citation moves from `link/v4.md` to `v7.md`.
* **Protocol versions** — the most recent bump touched *five* repositories, and
  the `website` row is the interesting one: core is normally out of a protocol
  bump's reach and this one reached it, because what changed was not a game noun
  but the shape of a thing core owns the ledger for. The store-migration
  paragraph now says four bumps' worth rather than two.
* Two capability entries, so `/`, `/features/` and `/modules/` stop omitting the
  subsystem — an Administration item, and an **Event calendar** under Community
  with `/site/events` as its deep link. Deliberately *not* `needsModule`: a bare
  core can author and run an event, and only the world verbs need a module.
* **`reference/event-catalog` is retitled "Shard event catalog"** and says what
  it is not. Two things in the docs were called an event catalog; the route is
  unchanged, so nothing outside this repository breaks.
* `canonicalDocs` gains `website/EVENTS.md` and moves `link/v4.md` → `v7.md`.

No screenshots. Capturing the events surfaces means standing the whole rig back
up — game server, sidecar, core, module, a published event with a live run — for
two or three images that no check requires, and the engagement workstream's own
site leg added none either.

`npm run verify` green end to end, including `checkReference` against the
protocol spec that only reached `docs` `main` in RunicGateway/docs#232 — the
seventh cutover step, which 16b had left on `edge`.

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

src/data/collection.mjs

@@ -471,6 +471,35 @@ export const collected = [
       'website server/db/schema.sql — engagement_sends, engagement_suppressions, ' +
       'notification_channel_prefs; server/src/utils/engagementRetentionPrune.js',
   },
+  {
+    id: 'deploy-events',
+    scope: 'deployment',
+    title: 'Who took part in a scheduled event',
+    body:
+      'Where the operator runs scheduled events, a run can count who took part — kept as ' +
+      'the name the game module knows a participant by, a score, and a rank, linked to a ' +
+      'site account where one is linked and left unlinked where it is not. That is what ' +
+      'the published results table renders, and what a signed-in person sees as their own ' +
+      'event history. Beside it the site records what each run did: which step ran, what ' +
+      'it created or borrowed in the game world, whether the undo succeeded, and which ' +
+      'staff account started, paused or cancelled it.',
+    retention: {
+      summary:
+        "A run's diagnostic log is swept after 90 days; the run itself and its participants " +
+        'are kept until the operator removes them',
+      detail:
+        'The log that answers "why did this run stall" is deleted 90 days after a run ' +
+        'reaches a terminal state, and only then — a run still in flight keeps every line ' +
+        'it has, however old, because the question it answers is still open. The run, its ' +
+        'steps, what it created and its participant list are not swept: they are the ' +
+        'record of what was done to a shared world, and deleting one silently would ' +
+        'unmake an audit. Deleting an account detaches its participation rows rather than ' +
+        'removing them — the result table keeps the score and stops naming a person.',
+    },
+    source:
+      'website server/db/schema.sql — event_runs, event_run_participants, ' +
+      'event_run_resources, event_run_log; server/src/utils/eventRunner.js',
+  },
   {
     id: 'deploy-game-data',
     scope: 'deployment',
@@ -481,7 +510,7 @@ export const collected = [
       'Which of it is visible to the public is the operator’s decision, made in the ' +
       'admin panel — the bridge itself forwards, and the site decides.',
     retention: { summary: 'Operator-configured' },
-    source: 'docs/link/v4.md — the visibility framework',
+    source: 'docs/link/v7.md — the visibility framework',
   },
 ];