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/routes/admin/AdminLayout.jsx

@@ -6,6 +6,9 @@ import { useAuth } from '../../contexts/AuthContext.jsx'
 import { useSite } from '../../contexts/SiteContext.jsx'
 import { applyNavOverrides } from '../../lib/navOverrides.js'
 import { useNavOverrides } from '../../lib/useNavOverrides.js'
+import { withModuleNav } from '../../modules/nav.js'
+import { useFeatureGate } from '../../modules/features.jsx'
+import { navItemVisibleTo, allowedPathsFor, isAllowedPath } from '../../lib/adminNav.js'
 
 // Small inline stroke icons (16px, currentColor) — same style as ProviderIcon.
 // One shared frame keeps them terse; each item just supplies its path(s).
@@ -104,10 +107,6 @@ export const NAV = [
 
 const COLLAPSE_KEY = 'admin.nav.collapsed'
 
-// Moderators only get the moderation section (Discord + in-game ops) + their
-// own account security.
-const MOD_PATHS = ['/admin/moderation', '/admin/moderation/appeals', '/admin/shard-ops', '/admin/houses', '/admin/account']
-
 // The one row an override may never hide: the nav editor itself, which is the
 // only screen that can un-hide anything. The write path already refuses it
 // (server/src/utils/navOverrides.js) and the editor's own toggle is disabled —
@@ -123,15 +122,11 @@ function keepEditorReachable(overrides) {
   return { ...overrides, [UNHIDEABLE]: rest }
 }
 
-// Who may see a sidebar row. The single authority for that question: the layout
-// applies it after the override merge (overrides are presentation, this is the
-// boundary — §7), and Admin -> Navigation applies it to build its palette, so an
-// admin is never offered a row they cannot themselves see (§8.1).
-export function navItemVisibleTo(item, role) {
-  if (item.roles && !item.roles.includes(role)) return false
-  if (role === 'moderator') return MOD_PATHS.includes(item.to)
-  return true
-}
+// Who may see a sidebar row, and where that lets them go, both derived from the
+// row's own `roles` — lib/adminNav.js, which is where the two hardcoded path
+// lists this component used to carry went (MODULE_SYSTEM.md §1.4). Re-exported
+// because Admin -> Navigation has always imported it from here.
+export { navItemVisibleTo }
 
 const TITLES = {
   '/admin': 'Dashboard',
@@ -159,6 +154,19 @@ const TITLES = {
   '/admin/account': 'Account Security',
 }
 
+// An installed module's admin pages are not in TITLES and cannot be — core does
+// not know what they are called. Their nav row does, so the row is the title:
+// the longest matching module row wins, so a detail page under a section titles
+// as that section rather than falling through to a bare "Admin". Restricted to
+// rows a module registered, which is what keeps every core path resolving
+// through TITLES and sectionTitle exactly as it does today.
+function moduleTitle(baseNav, pathname) {
+  return baseNav
+    .flatMap((g) => g.items)
+    .filter((i) => i.moduleId && (pathname === i.to || pathname.startsWith(`${i.to}/`)))
+    .sort((a, b) => b.to.length - a.to.length)[0]?.label
+}
+
 // Fallback page title for dynamic sub-routes not in the exact-match TITLES map.
 function sectionTitle(pathname) {
   if (pathname.startsWith('/admin/moderation')) return 'Moderation'
@@ -186,7 +194,15 @@ export default function AdminLayout() {
   const navOverrides = useNavOverrides()
   const navigate = useNavigate()
   const location = useLocation()
-  const title = TITLES[location.pathname] || sectionTitle(location.pathname)
+  const isVisible = useFeatureGate()
+
+  // Core's rows plus every installed module's, before the override merge sees
+  // them — so a module row is editable in Admin -> Navigation like any other
+  // (modules/nav.js). Computed once: the registry is fixed before the first
+  // render and nothing unregisters.
+  const baseNav = useMemo(() => withModuleNav(NAV, 'admin'), [])
+  const title =
+    TITLES[location.pathname] || moduleTitle(baseNav, location.pathname) || sectionTitle(location.pathname)
   // The hero canvas editor needs room — let it use the full content width.
   const wide = location.pathname === '/admin/hero'
   const modeDot = mode === 'live' ? 'var(--mode-live)' : 'var(--mode-maint)'
@@ -200,11 +216,17 @@ export default function AdminLayout() {
   // NAV itself and this is exactly the code that ran before the feature.
   const navGroups = useMemo(
     () =>
-      applyNavOverrides(NAV, keepEditorReachable(navOverrides.nav_admin))
-        .map((g) => ({ ...g, items: g.items.filter((item) => navItemVisibleTo(item, user?.role)) }))
+      applyNavOverrides(baseNav, keepEditorReachable(navOverrides.nav_admin))
+        .map((g) => ({
+          ...g,
+          // `isVisible` is a no-op for every core row — none carries a `feature`
+          // — and is applied here so that a module row which does carry one is
+          // gated on the sidebar rather than silently advertised.
+          items: g.items.filter((item) => navItemVisibleTo(item, user?.role) && isVisible(item)),
+        }))
         // Drop any now-empty group so an empty category header never renders.
         .filter((g) => g.items.length > 0),
-    [navOverrides.nav_admin, user?.role],
+    [baseNav, navOverrides.nav_admin, user?.role, isVisible],
   )
 
   // Accordion: track which titled categories are collapsed. Persist across
@@ -231,17 +253,22 @@ export default function AdminLayout() {
     g.title && g.items.some((i) => (i.end ? location.pathname === i.to : location.pathname.startsWith(i.to)))
   )?.title
 
+  // Where a moderator may go, from the same `roles` that decide what they see.
+  // It used to be a third hardcoded list — a prefix check over three paths —
+  // which disagreed with the sidebar's own five-path allowlist: `/admin/houses`
+  // was on the sidebar and not in the redirect, so a moderator who clicked
+  // Houses in their own nav was bounced straight back to Moderation. One
+  // derivation cannot disagree with itself, which is the point of deriving it.
+  const allowed = useMemo(() => allowedPathsFor(baseNav, user?.role), [baseNav, user?.role])
+
   // Confine a moderator who deep-links (or is redirected to the index) to a page
   // outside their remit — the API would 403 anyway, so send them to their home.
   useEffect(() => {
     if (!isModerator) return
-    const p = location.pathname
-    const allowed =
-      p.startsWith('/admin/moderation') || p.startsWith('/admin/shard-ops') || p === '/admin/account'
-    if (!allowed) {
+    if (!isAllowedPath(location.pathname, allowed)) {
       navigate('/admin/moderation', { replace: true })
     }
-  }, [isModerator, location.pathname, navigate])
+  }, [isModerator, location.pathname, navigate, allowed])
 
   // Keep the admin out of search indexes (belt-and-suspenders with robots.txt).
   useEffect(() => {

client/src/routes/admin/views/NavEditor.jsx

@@ -13,7 +13,8 @@ import { Loading, ErrorState } from '../../../components/PageState.jsx'
 import { api } from '../../../api/client.js'
 import { useAuth } from '../../../contexts/AuthContext.jsx'
 import { useSite } from '../../../contexts/SiteContext.jsx'
-import { useShardFeatures, canSee } from '../../../lib/useShardFeatures.js'
+import { withModuleNav } from '../../../modules/nav.js'
+import { useFeatureGate } from '../../../modules/features.jsx'
 import { buildNavRows, buildNavOverrides, buildPublicNav, buildPublicNavOverrides } from '../../../lib/navOverrides.js'
 import PublicNavTree from './PublicNavTree.jsx'
 import { parseJsonSetting } from '../../../lib/settingsJson.js'
@@ -244,7 +245,7 @@ export function Row({ row, id, destinations, destination, onDestination, onChang
 export default function NavEditor() {
   const { user } = useAuth()
   const { refresh: refreshSite } = useSite()
-  const shardFeatures = useShardFeatures()
+  const isVisible = useFeatureGate()
   const [tab, setTab] = useState('nav_public')
   // Per nav: the editable groups, the overrides as loaded (so a row this admin
   // cannot see survives their save), and whether a settings row exists at all.
@@ -255,25 +256,39 @@ export default function NavEditor() {
   const [saved, setSaved] = useState('')
   const [dirty, setDirty] = useState({})
 
-  // The palette: each base nav, filtered to what THIS admin can see (§8.1). The
-  // public nav's gates are the shard-feature ones; the admin nav's are roles.
-  // The player portal has no gates at all.
   // The nav as coded, unfiltered. The palette below is what this admin may EDIT;
   // this is what still EXISTS, and the two are different questions. Saving needs
   // both: an entry for a row their palette filtered out must be carried through
   // rather than reset, and only an entry for a route the code no longer declares
   // at all should be dropped.
-  const fullNavs = { nav_public: PUBLIC_NAV, nav_admin: ADMIN_NAV, nav_player: PLAYER_NAV }
+  //
+  // Each nav is the coded array with every installed module's rows already
+  // interleaved (modules/nav.js) — the same array the layout renders, which is
+  // what makes a module row editable here at all: the override merge is keyed by
+  // `to` and drops a key the base it is handed does not declare, so a nav built
+  // from core alone would silently discard every stored override on a module row
+  // the moment it was saved.
+  const fullNavs = useMemo(
+    () => ({
+      nav_public: withModuleNav(PUBLIC_NAV, 'public'),
+      nav_admin: withModuleNav(ADMIN_NAV, 'admin'),
+      nav_player: withModuleNav(PLAYER_NAV, 'player'),
+    }),
+    [],
+  )
 
+  // The palette: each base nav, filtered to what THIS admin can see (§8.1). Two
+  // gates, and neither is core's own opinion any more — `roles` on a row, and
+  // the owning module's answer for a row that names a `feature`.
   const palettes = useMemo(
     () => ({
-      nav_public: PUBLIC_NAV.filter((item) => !item.feature || canSee(shardFeatures, item.feature)),
-      nav_admin: ADMIN_NAV.map((g) => ({ ...g, items: g.items.filter((i) => navItemVisibleTo(i, user?.role)) })).filter(
-        (g) => g.items.length > 0,
-      ),
-      nav_player: PLAYER_NAV,
+      nav_public: fullNavs.nav_public.filter(isVisible),
+      nav_admin: fullNavs.nav_admin
+        .map((g) => ({ ...g, items: g.items.filter((i) => navItemVisibleTo(i, user?.role) && isVisible(i)) }))
+        .filter((g) => g.items.length > 0),
+      nav_player: fullNavs.nav_player.filter(isVisible),
     }),
-    [shardFeatures, user?.role],
+    [fullNavs, isVisible, user?.role],
   )
 
   useEffect(() => {

client/src/routes/player/PlayerPortalLayout.jsx

@@ -6,6 +6,8 @@ import { useAuth } from '../../contexts/AuthContext.jsx'
 import { useSite } from '../../contexts/SiteContext.jsx'
 import { applyNavOverrides } from '../../lib/navOverrides.js'
 import { useNavOverrides } from '../../lib/useNavOverrides.js'
+import { withModuleNav } from '../../modules/nav.js'
+import { useFeatureGate } from '../../modules/features.jsx'
 
 // Shared shell for the logged-in player portal. Uses the same sidebar shell as
 // Admin (icon nav, sticky content header, footer sign-out) so the two logged-in
@@ -35,9 +37,10 @@ const IconGear = () => <Icon><circle cx="12" cy="12" r="3" /><path d="M12 2v3M12
 const IconShield = () => <Icon><path d="M12 3l7 3v5c0 5-3.5 8-7 10-3.5-2-7-5-7-10V6z" /><path d="M9 12l2 2 4-4" /></Icon>
 
 // Exported because Admin -> Navigation edits this list. It stays declared here;
-// the editor may only relabel, reorder and hide what it finds (§7). No row
-// carries a gate — every player sees all three — so the merged result is what
-// renders, with no filter after it.
+// the editor may only relabel, reorder and hide what it finds (§7). No CORE row
+// carries a gate — every player sees all three — but an installed module's rows
+// join this list before the merge and may carry a `feature`, so the filter after
+// it is not dead code.
 export const NAV = [
   { to: '/player', label: 'Characters', end: true, icon: IconUser },
   { to: '/account/appeals', label: 'Appeals', icon: IconShield },
@@ -69,7 +72,12 @@ export default function PlayerPortalLayout() {
   const { user, logout } = useAuth()
   const { siteTitle } = useSite()
   const navOverrides = useNavOverrides()
-  const nav = useMemo(() => applyNavOverrides(NAV, navOverrides.nav_player), [navOverrides.nav_player])
+  const isVisible = useFeatureGate()
+  const baseNav = useMemo(() => withModuleNav(NAV, 'player'), [])
+  const nav = useMemo(
+    () => applyNavOverrides(baseNav, navOverrides.nav_player).filter(isVisible),
+    [baseNav, navOverrides.nav_player, isVisible],
+  )
   const navigate = useNavigate()
   const location = useLocation()
   const title =