feat(modules): the three de-entanglement registries, with core as the registrant

Phase 2 PR 4 of docs/website/MODULE_SYSTEM.md §2.7. Adds server/src/modules/registries.js
and moves core's own notification streams, announce leg and users-detail routes
behind it, so the three seams §1.8 and §1.9 named are exercised on every boot
before any module depends on them.

Registering is validate-then-commit per registrant: the loader stages what a
module claims and the second pass commits it, so a module that throws halfway
through register() — or fails checkDeclared after it — leaves nothing behind.
That is the registry-side twin of PR 2's second-pass mount rule.

Four decisions, all the recommended option:

- announce legs became a child table. `announce_job_legs` replaces the
  towncrier_*/discord_* column groups, so the leg set is data: core registers
  `discord`, module-uo will register `towncrier`, and a module cannot ALTER a
  core table to add its own. Backfill is guarded on information_schema (a
  SELECT of a dropped column is a parse error, not a runtime one) and the
  columns go with DROP COLUMN IF EXISTS. Verified against the live dev DB:
  three legacy jobs migrated faithfully, three replays, no duplicates.
- `mapEvent` dropped from registerNotificationStreams. §1.8 already inverts the
  push path so a module owns fromShardEvent and calls core's publish() with a
  stream id it resolved; a second mapping mechanism was a leftover. The public
  safety filter, the kinds it reads and the streams it protects now live in one
  file and move together.
- core registers through the same staging area a module uses, via an explicit
  registries.registerCore() in app.js before modules.load().
- core's six /admin/users/:id/shard/* paths now go through the
  `admin.users.detail` slot, and getUser moved back to admin.controller.js.

Found on the way, and the reason two build tools changed:

- scripts/routeManifest.js could not decode a parameterised mount. Its
  unwinder expected `(?:([^\/]+?))`; express 4.22 emits `(?:\/([^/]+?))` with
  the separator inside the group. The branch had never run. It threw rather
  than guessing, which is what it is for.
- swagger-autogen cannot follow a route into an extension slot — the slot's
  router is created by declareSlot() and filled later, so there is no literal
  mount for a static parse. Regenerating deleted 407 lines and printed
  `Swagger-autogen: Success`, the spike's exact failure (MODULE_API.md §7.4).
  swagger/slotSpecs.js generates a fragment per filled slot and re-roots it at
  the prefix the router actually hangs at in the live app — read from the
  express stack via routeManifest's own mountPath, so the manifest and the spec
  cannot disagree. swagger/mergeSpec.js is the merge helper core owes for
  module fragments anyway (§6.1a), proved here against core's own slot first.

884 tests pass (856 before). routes.manifest.json is unchanged at 229 routes.
The OpenAPI spec diff is two lines of intent: the retry endpoint's summary, and
its `leg` no longer being a fixed enum.

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

server/db/schema.sql

@@ -1106,35 +1106,79 @@ CREATE TABLE IF NOT EXISTS pages (
 
 -- Announcement pipeline. One row per publish event of a news post; the table
 -- doubles as the job queue (a light in-process poller — utils/announceWorker.js
--- — sweeps it for due legs). Two INDEPENDENT delivery legs so a Discord outage
--- never blocks or retries the in-game town-crier leg and vice versa. `status` is
--- a derived rollup of the two legs (see announceJobs.logic.js): done when both
--- legs done, failed when both exhausted, partial in between. Each leg tracks its
--- own attempt count, last error, and next-due time for exponential backoff.
--- post_id is INT (matches posts.id) and cascades so deleting a post reaps its
--- jobs. posts.announce_job_id points back at the latest row for admin lookups.
+-- — sweeps it for due legs). `status` is a derived rollup of the legs (see
+-- announceJobs.logic.js): done when every leg is done, failed when every leg is
+-- exhausted, partial in between. post_id is INT (matches posts.id) and cascades
+-- so deleting a post reaps its jobs. posts.announce_job_id points back at the
+-- latest row for admin lookups.
 CREATE TABLE IF NOT EXISTS announce_jobs (
   id                        INT AUTO_INCREMENT PRIMARY KEY,
   post_id                   INT NOT NULL,
   status                    ENUM('pending','partial','done','failed') NOT NULL DEFAULT 'pending',
-
-  towncrier_status          ENUM('pending','done','failed') NOT NULL DEFAULT 'pending',
-  towncrier_attempts        SMALLINT NOT NULL DEFAULT 0,
-  towncrier_last_error      TEXT NULL,
-  towncrier_next_attempt_at DATETIME NULL,
-
-  discord_status            ENUM('pending','done','failed') NOT NULL DEFAULT 'pending',
-  discord_attempts          SMALLINT NOT NULL DEFAULT 0,
-  discord_last_error        TEXT NULL,
-  discord_next_attempt_at   DATETIME NULL,
-
   created_at                DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
   updated_at                DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
-  CONSTRAINT fk_announce_jobs_post FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE,
-  INDEX idx_announce_due (towncrier_status, towncrier_next_attempt_at),
-  INDEX idx_announce_due_discord (discord_status, discord_next_attempt_at)
+  CONSTRAINT fk_announce_jobs_post FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
+-- One row per delivery leg per job. INDEPENDENT by design: a Discord outage never
+-- blocks or retries another leg, and each leg tracks its own attempt count, last
+-- error and next-due time for exponential backoff.
+--
+-- This is a child table rather than a pair of leg-prefixed column groups on
+-- announce_jobs because the leg set is DATA now, not schema: core registers
+-- `discord`, module-uo registers `towncrier`, and a module for another game
+-- registers its own — through modules/registries.js's registerAnnounceLeg
+-- (MODULE_SYSTEM.md §1.8). A module cannot ALTER a core table, so a leg that
+-- needed its own columns could never come from a module at all. `leg` is a plain
+-- VARCHAR and not an ENUM for the same reason.
+CREATE TABLE IF NOT EXISTS announce_job_legs (
+  job_id                    INT NOT NULL,
+  leg                       VARCHAR(64) NOT NULL,
+  status                    ENUM('pending','done','failed') NOT NULL DEFAULT 'pending',
+  attempts                  SMALLINT NOT NULL DEFAULT 0,
+  last_error                TEXT NULL,
+  next_attempt_at           DATETIME NULL,
+  created_at                DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  updated_at                DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
+  PRIMARY KEY (job_id, leg),
+  CONSTRAINT fk_announce_job_legs_job FOREIGN KEY (job_id) REFERENCES announce_jobs(id) ON DELETE CASCADE,
+  INDEX idx_announce_leg_due (status, next_attempt_at)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+
+-- Carry the two hardcoded leg column groups over to the child table, once. Guarded
+-- on the OLD columns still existing (via information_schema, since a plain SELECT
+-- of a dropped column is a parse error, not a runtime one) and on there being no
+-- row already, so replaying this file on every boot is a no-op after the first.
+-- Deleting this block once every deployment has booted it is safe.
+SET @has_legacy_legs := (
+  SELECT COUNT(*) FROM information_schema.COLUMNS
+   WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'announce_jobs'
+     AND COLUMN_NAME = 'towncrier_status'
+);
+SET @sql := IF(@has_legacy_legs > 0,
+  'INSERT IGNORE INTO announce_job_legs (job_id, leg, status, attempts, last_error, next_attempt_at)
+     SELECT id, ''towncrier'', towncrier_status, towncrier_attempts, towncrier_last_error, towncrier_next_attempt_at FROM announce_jobs
+     UNION ALL
+     SELECT id, ''discord'', discord_status, discord_attempts, discord_last_error, discord_next_attempt_at FROM announce_jobs',
+  'DO 0');
+PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt;
+
+-- MariaDB's IF EXISTS makes this idempotent, so it replays cleanly like the rest
+-- of the file. It is the one DROP in core's schema, and it is deliberate: leaving
+-- the columns would leave `towncrier` in a core file, which Phase 3's acceptance
+-- grep forbids (MODULE_SYSTEM.md §2.7).
+ALTER TABLE announce_jobs
+  DROP COLUMN IF EXISTS towncrier_status,
+  DROP COLUMN IF EXISTS towncrier_attempts,
+  DROP COLUMN IF EXISTS towncrier_last_error,
+  DROP COLUMN IF EXISTS towncrier_next_attempt_at,
+  DROP COLUMN IF EXISTS discord_status,
+  DROP COLUMN IF EXISTS discord_attempts,
+  DROP COLUMN IF EXISTS discord_last_error,
+  DROP COLUMN IF EXISTS discord_next_attempt_at,
+  DROP INDEX IF EXISTS idx_announce_due,
+  DROP INDEX IF EXISTS idx_announce_due_discord;
+
 -- ── Spawn atlas (Protocol 3.0 Part C) ───────────────────────────────────────
 -- Static shard CONTENT, not live shard state: what spawns where, which regions
 -- and landmarks exist, and which champion altars are configured. Nothing here