feat(modules): the client registry, window.__rg and the chunk's script injection

Phase 2, PR 7 of docs/website/MODULE_SYSTEM.md 2.7 — the client half's
delivery. A module's prebuilt chunk is served, injected, handed core's React
and its UI kit, and its routes are rendered by App.jsx. The registry is empty
on a bare core, so nothing an operator can see changes.

Client:
  - modules/registry.js — registerRoutes/registerNav/registerFeatureProvider,
    with the URL namespace written by core, never by the module
  - modules/shared.js — window.__rg: React, react-dom/client, react-router-dom,
    react/jsx-runtime, the registry, the seven-member UI kit and the request
    primitive, frozen
  - App.jsx reads routesFor for all three areas; nav consumption is PR 8
  - main.jsx publishes the global, then mounts on DOMContentLoaded

Server:
  - the loader validates client.entry and publishes clientChunks() and
    clientEntryUrls(); an entry in the module root is rejected, because the
    directory it sits in is what gets served
  - app.js mounts each chunk at /modules/<id>/ behind the module's state guard
    with no-cache; anything else under /modules is a 404, not the SPA shell
  - htmlShell injects the tag before </body>, so core's bundle runs first
    wherever a bundler puts it

Found by loading a real chunk in a browser, and fixed here: core mounted before
any module chunk had evaluated, because document.readyState during a deferred
script is 'interactive', not 'loading'. Every test passed against that build.
The smoke is written down in MODULE_API.md 7.7.

933 server tests (+23), 123 client tests (+14). routes.manifest.json unchanged
at 230 routes; the OpenAPI spec regenerates byte-identical.

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

client/src/modules/registry.js

@@ -0,0 +1,137 @@
+// ── The client-side module registry ────────────────────────────────────────
+//
+// Phase 2, PR 7 of docs/website/MODULE_SYSTEM.md §2.7. The normative contract is
+// docs/website/MODULE_API.md §3.3; where the two disagree, the contract wins.
+//
+// A module's prebuilt chunk registers its routes, its nav entries and its feature
+// provider here, and core reads them back. This is the client twin of the
+// server's modules/loader.js — with one structural difference worth stating,
+// because it is what makes the file this short: core *hands* the registry to the
+// module (on `window.__rg`, see shared.js) rather than discovering it. There is
+// nothing to scan, nothing to validate a manifest against, and no failure mode
+// where half a module is registered.
+//
+// **Timing is the whole design.** Module chunks are `<script type="module" src>`
+// tags the server injects before `</body>` (server/src/utils/htmlShell.js), after
+// core's own bundle. Module scripts are deferred, so they evaluate after that
+// bundle has run — which is where `window.__rg` is published — and all of them
+// finish before DOMContentLoaded. main.jsx waits for that same event before
+// calling render(), so registration is complete before React reads any of this.
+//
+// That is what buys the simplicity here: registration is a plain synchronous
+// write with no subscribers, not an observable store, because nothing can
+// register after the first render. If that ever stops being true it changes in
+// this file and in main.jsx, not in a dozen consumers.
+//
+// What PR 7 wires up is `routesFor` (App.jsx). `navFor` and `featureProviderFor`
+// are stored and returned faithfully but core does not read them yet — PR 8 adds
+// the nav interleave and the feature-provider seam. Storing them is not the kind
+// of accepting stub the server's registries refused to be: nothing is discarded
+// here, so a module that registers nav in this core gets it back from `navFor`.
+
+const routes = { public: [], admin: [], player: [] }
+const nav = { public: [], admin: [], player: [] }
+const featureProviders = new Map()
+const registered = new Set()
+
+const AREAS = ['public', 'admin', 'player']
+
+function assertArea(area, call) {
+  if (!AREAS.includes(area)) throw new Error(`${call}: unknown area "${area}"`)
+}
+
+/**
+ * Route components, by area.
+ *
+ * @param {string} id  the module id — the URL segment its routes are namespaced under
+ * @param {{public?: Array, admin?: Array, player?: Array}} byArea
+ *   each entry `{ path, element, gate? }`. `path` is relative to the module's
+ *   namespace; core prefixes it and mounts it inside the area's existing wrapper
+ *   (`/<id>/…` under MaintenanceGate, `/admin/<id>/…` under RequireAuth +
+ *   AdminLayout, `/player/<id>/…` under RequirePlayer + PlayerPortalLayout).
+ *   `gate` is an optional `{ roles: [...] }` that core applies as its own
+ *   RoleGate — a module cannot supply an auth wrapper, because the sidebar and
+ *   the route table have to agree about who may see what (§3.3).
+ */
+export function registerRoutes(id, byArea) {
+  for (const [area, list] of Object.entries(byArea || {})) {
+    assertArea(area, 'registerRoutes')
+    for (const route of list || []) {
+      // Prefixed HERE rather than by the module: a module cannot claim a path
+      // outside its own namespace however it spells `path` — a leading `/`, a
+      // trailing one, or several — because it never gets to write the segment
+      // its routes hang under.
+      const path = `${id}/${String(route.path || '').replace(/^\/+/, '')}`.replace(/\/+$/, '')
+      routes[area].push({ ...route, path, moduleId: id })
+    }
+  }
+  registered.add(id)
+}
+
+/**
+ * Nav entries, interleaved into CORE groups rather than appended as a block.
+ *
+ * Today's UO items sit inside core's own Moderation and System groups; a "UO"
+ * group at the bottom of the sidebar would be a visible regression on the day
+ * the module is extracted (MODULE_SYSTEM.md §1.4). `group` names an existing
+ * core group, `order` sorts within it, and an unknown group name appends rather
+ * than dropping the item — a mis-typed group must cost a position, never a link.
+ *
+ * @param {string} id
+ * @param {{area: string, items: Array<{label, to, group?, order?, roles?, feature?}>}} spec
+ */
+export function registerNav(id, spec) {
+  const { area, items } = spec || {}
+  assertArea(area, 'registerNav')
+  for (const item of items || []) nav[area].push({ ...item, moduleId: id })
+  registered.add(id)
+}
+
+/**
+ * The hook that answers "which of this module's features may this viewer see".
+ *
+ * Core keeps a generic flag context and owns none of the semantics — `uo` fills
+ * its namespace with today's `useShardFeatures` (MODULE_SYSTEM.md §1.5). With no
+ * module installed the nav filter is a correct no-op, because no core nav item
+ * carries a `feature` today.
+ */
+export function registerFeatureProvider(id, namespace, hook) {
+  featureProviders.set(namespace, { id, hook })
+  registered.add(id)
+}
+
+export const routesFor = (area) => routes[area] || []
+
+// Sorted by the `order` a module asked for. Array#sort is stable in every engine
+// this ships to, so two modules asking for the same slot keep load order —
+// which is alphabetical by id, the same order the server scans in (§4.2).
+export const navFor = (area) =>
+  [...(nav[area] || [])].sort((a, b) => (a.order ?? 100) - (b.order ?? 100))
+
+export const featureProviderFor = (namespace) => featureProviders.get(namespace)
+
+export const registeredIds = () => [...registered]
+
+/** Test seam. Nothing in the app calls this — there is no unregistering. */
+export function _reset() {
+  for (const area of AREAS) {
+    routes[area].length = 0
+    nav[area].length = 0
+  }
+  featureProviders.clear()
+  registered.clear()
+}
+
+// The object handed to modules on window.__rg.registry. Deliberately the write
+// calls plus the read ones: a module reading `routesFor` is how it finds out
+// another module is installed, which is the only supported form of module-to-
+// module awareness (there is no dependency resolution).
+export const registry = {
+  registerRoutes,
+  registerNav,
+  registerFeatureProvider,
+  routesFor,
+  navFor,
+  featureProviderFor,
+  registeredIds,
+}