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/src/components/SiteHeader.jsx

@@ -4,22 +4,28 @@ import MoonDot from './MoonDot.jsx'
 import BrandLogo from './BrandLogo.jsx'
 import { useAuth } from '../contexts/AuthContext.jsx'
 import { useSite } from '../contexts/SiteContext.jsx'
-import { useShardFeatures, canSee } from '../lib/useShardFeatures.js'
 import NavDropdown from './NavDropdown.jsx'
 import { buildPublicNav, pruneNav } from '../lib/navOverrides.js'
 import { parseJsonSetting } from '../lib/settingsJson.js'
+import { withModuleNav } from '../modules/nav.js'
+import { useFeatureGate } from '../modules/features.jsx'
 
 // One consistent top nav for the whole public site. Every page gets the same
 // main links plus an auth-aware entry on the right (Sign in / My Account / Admin).
 //
-// Entries carrying a `feature` are shard surfaces an admin can disable or gate
-// to a higher audience (Admin -> Shard Visibility). They are hidden when this
-// viewer can't reach them, so we never render a link that would 403. The gate
-// itself is server-side; this is only about not advertising a dead end.
+// Entries carrying a `feature` are surfaces an admin can disable or gate to a
+// higher audience (Admin -> Shard Visibility). They are hidden when this viewer
+// can't reach them, so we never render a link that would 403. The gate itself is
+// server-side; this is only about not advertising a dead end. Which module
+// answers for a given flag is the registry's business now, not this file's —
+// core registers `useShardFlags` for the ten below and Phase 3 hands them over
+// (modules/featureGate.js).
 //
 // Exported because Admin -> Navigation edits this list. It stays declared here,
 // with this component as its owner: the editor may only relabel, reorder and
-// hide what it finds, and `to`/`feature` are never its to change (§7).
+// hide what it finds, and `to`/`feature` are never its to change (§7). An
+// installed module's rows join it in `withModuleNav` below — before the override
+// merge, so an admin can edit those rows exactly as they edit these.
 export const NAV = [
   { label: 'Home', to: '/', end: true },
   { label: 'News', to: '/site/news' },
@@ -48,7 +54,12 @@ const linkStyle = ({ isActive }) => ({
 export default function SiteHeader() {
   const { user, loading } = useAuth()
   const { siteTitle, settings } = useSite()
-  const shardFeatures = useShardFeatures()
+  const isVisible = useFeatureGate()
+
+  // Core's rows plus every installed module's. Computed once: the registry is
+  // fixed before the first render and there is no unregistering, so this cannot
+  // change during a session (modules/nav.js).
+  const baseNav = useMemo(() => withModuleNav(NAV, 'public'), [])
 
   // An admin may relabel, reorder and hide these entries from Admin →
   // Navigation, and may group them into dropdown sections alongside links of
@@ -62,9 +73,9 @@ export default function SiteHeader() {
   //   • with no stored row this is the coded NAV, in code order, so an
   //     untouched instance renders exactly what it renders today.
   const nav = useMemo(() => {
-    const tree = buildPublicNav(NAV, parseJsonSetting(settings.nav_public))
-    return pruneNav(tree, (item) => !item.feature || canSee(shardFeatures, item.feature))
-  }, [settings.nav_public, shardFeatures])
+    const tree = buildPublicNav(baseNav, parseJsonSetting(settings.nav_public))
+    return pruneNav(tree, isVisible)
+  }, [baseNav, settings.nav_public, isVisible])
 
   // Where the auth entry points: staff → admin, player → portal, else sign in.
   let account