feat(modules): interleave module nav, derive moderator confinement

Phase 2, PR 8 of docs/website/MODULE_SYSTEM.md 2.7 - the nav half PR 7
deferred, plus the two seams 1.4 and 1.5 asked for.

withModuleNav (client/src/modules/nav.js) merges an installed module's rows
into core's three navs BEFORE the admin-override merge, and that ordering is
the design. applyNavOverrides and buildPublicNav are keyed by `to` and drop
any key their base array does not declare, so rows appended after the merge
would be unorderable, unrelabellable and unhideable in Admin - Navigation.
Today's UO rows are all three of those things, so appending would make the
extraction a visible regression for anyone who has ever edited their nav.
Merging first means a module row is an ordinary row downstream: nothing in
navOverrides.js, NavEditor.jsx or the layouts knows a module exists.

MOD_PATHS is gone. Moderator visibility and the redirect that confines a
moderator both derive from each row's own `roles`, in the new plain-JS
lib/adminNav.js (plain so the DOM-less runner can reach it). Two rows move,
both toward what the server already permitted: Dashboard, whose roles had
always named moderator, and My Characters, which is ungated self-service.

That also fixes a defect predating the module system. The redirect was a
THIRD hardcoded list - three path prefixes against MOD_PATHS' five paths -
and they disagreed about /admin/houses, so a moderator who clicked Houses in
their own sidebar was bounced back to Moderation. The derived allow-list is
computed from the BASE nav, never the override-merged one: an override is
presentation and must not move an authorization boundary either way.

The feature seam (modules/features.jsx + modules/featureGate.js) resolves a
row's `feature` against the provider its OWN module registered, so the
namespace comes from the registration and no string carries a parsed prefix.
Core registers useShardFlags under the owner id `core` - the client twin of
registries.registerCore() - so the ten shard-gated header rows already run
through the seam and Phase 3 deletes a registration instead of rewriting
SiteHeader. Every unknown fails open: no provider, a null answer while a
fetch is in flight, or a junk return all show the link, because the server is
the gate and hiding a page from someone entitled to it is the worse mistake.

933 server tests (unchanged - this PR is client-only), 160 client tests
(+37). routes.manifest.json unchanged at 230 routes; the OpenAPI spec
regenerates byte-identical.

Re-ran the MODULE_API.md 7.7 browser smoke, since this is the seam that rule
exists for. A throwaway module registering nav in all three areas and a
provider granting one flag and withholding another: the row lands inside
core's Moderation group rather than an appended block, the withheld row does
not render, a moderator reaches both /admin/houses and the module's admin
page, and an admin can relabel a module row and have it persist and apply.
Zero CSP reports, zero console errors.

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

client/test/featureGate.test.js

@@ -0,0 +1,85 @@
+import { test } from 'node:test'
+import assert from 'node:assert/strict'
+
+import { buildFeatureGate, OPEN_GATE } from '../src/modules/featureGate.js'
+
+// The feature seam's decision logic (MODULE_SYSTEM.md §1.5, MODULE_API.md §3.3).
+// Every branch here fails OPEN, and that is the property under test as much as
+// the happy path: this is presentation, the server is the gate, and a UI mistake
+// that hides a page from someone entitled to it is worse in every case than one
+// that shows a link which then 403s.
+
+const flags = (...names) => new Set(names)
+
+test('a row with no feature is always visible', () => {
+  const gate = buildFeatureGate(new Map([['uo', flags()]]))
+  assert.equal(gate({ to: '/site/news' }), true)
+})
+
+test('a core row resolves against the owner id `core`', () => {
+  // Core's ten shard-gated rows carry no moduleId, and core registers its
+  // provider under `core` (main.jsx) precisely so they resolve without one.
+  const gate = buildFeatureGate(new Map([['core', flags('atlas')]]))
+  assert.equal(gate({ to: '/site/atlas', feature: 'atlas' }), true)
+  assert.equal(gate({ to: '/site/market', feature: 'market' }), false)
+})
+
+test('a module row resolves against ITS module, not another one', () => {
+  const gate = buildFeatureGate(
+    new Map([
+      ['uo', flags('atlas')],
+      ['rust', flags('market')],
+    ]),
+  )
+  assert.equal(gate({ to: '/uo/atlas', feature: 'atlas', moduleId: 'uo' }), true)
+  // `market` is a flag the OTHER module grants. Resolution is by registration,
+  // so there is no string a module can write to borrow it.
+  assert.equal(gate({ to: '/uo/market', feature: 'market', moduleId: 'uo' }), false)
+  assert.equal(gate({ to: '/rust/market', feature: 'market', moduleId: 'rust' }), true)
+})
+
+test('no provider for the owner shows the row', () => {
+  // The no-module-installed case, and the reason the filter is a correct no-op
+  // on a bare core rather than a nav that renders nothing.
+  const gate = buildFeatureGate(new Map())
+  assert.equal(gate({ to: '/site/atlas', feature: 'atlas' }), true)
+  assert.equal(gate({ to: '/uo/atlas', feature: 'atlas', moduleId: 'uo' }), true)
+})
+
+test('a provider still loading shows the row', () => {
+  // useShardFlags returns null until its fetch lands. Blanking the nav on every
+  // page load and filling it in a moment later is the behaviour this avoids.
+  const gate = buildFeatureGate(new Map([['core', null]]))
+  assert.equal(gate({ to: '/site/atlas', feature: 'atlas' }), true)
+})
+
+test('a provider that returned something unusable shows the row', () => {
+  for (const bad of [undefined, 42, 'atlas', {}, []]) {
+    const gate = buildFeatureGate(new Map([['core', bad]]))
+    assert.equal(gate({ to: '/site/atlas', feature: 'atlas' }), true, `failed closed on ${JSON.stringify(bad)}`)
+  }
+})
+
+test('an array-backed provider is not silently treated as a Set', () => {
+  // `[].has` does not exist, so this is the unusable case above rather than a
+  // membership test that quietly always fails. Asserted so that a future
+  // "helpful" normalisation knows it changed a documented behaviour.
+  const gate = buildFeatureGate(new Map([['core', ['atlas']]]))
+  assert.equal(gate({ to: '/site/atlas', feature: 'atlas' }), true)
+})
+
+test('a missing map, or a junk row, shows rather than throws', () => {
+  assert.equal(buildFeatureGate(null)({ feature: 'atlas' }), true)
+  assert.equal(buildFeatureGate(new Map())(null), true)
+  assert.equal(buildFeatureGate(new Map())(undefined), true)
+})
+
+test('any Set-like satisfies a provider — core does not require a Set', () => {
+  const gate = buildFeatureGate(new Map([['uo', { has: (name) => name === 'ruleset' }]]))
+  assert.equal(gate({ feature: 'ruleset', moduleId: 'uo' }), true)
+  assert.equal(gate({ feature: 'champs', moduleId: 'uo' }), false)
+})
+
+test('the open gate is what a component outside the provider gets', () => {
+  assert.equal(OPEN_GATE({ feature: 'anything' }), true)
+})