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/lib/adminNav.js

@@ -0,0 +1,64 @@
+// Who may see a row of the admin sidebar, and where that lets them go.
+//
+// Plain JS, in its own file, for two reasons. It is shared — AdminLayout renders
+// by it and Admin -> Navigation builds its palette by it (THEMING_AND_NAV.md
+// §8.1), and a second copy of this answer is exactly the thing this file exists
+// to abolish. And it is the closest thing in the client to an authorization
+// decision, so it belongs somewhere the test runner can reach, which a .jsx file
+// is not.
+//
+// **A row's own `roles` is the whole answer.** Until Phase 2 PR 8 this was
+// `roles` AND a hardcoded `MOD_PATHS` list of five paths that confined
+// moderators, AND a third prefix list in the redirect effect that disagreed with
+// both (docs/website/MODULE_SYSTEM.md §1.4). A module's rows could never be
+// added to a list core hardcodes, which is what forced the derivation — but the
+// lists had already drifted from each other without a module in sight.
+
+/**
+ * Can a viewer with this role see this row?
+ *
+ * Applied AFTER the override merge in both callers: an override is presentation
+ * and this is the boundary, so an override saying `hidden: false` on a row this
+ * role cannot see still shows nothing (THEMING_AND_NAV.md §7).
+ *
+ * A row with no `roles` is visible to everyone who reached the admin area at
+ * all — that is the self-service case (Account, My Characters), and staff are a
+ * superset of players.
+ */
+export function navItemVisibleTo(item, role) {
+  return !item.roles || item.roles.includes(role)
+}
+
+/**
+ * The paths a viewer with this role may reach, derived from the rows they see.
+ *
+ * Takes the BASE nav, never the override-merged one: an override must not be
+ * able to move this boundary in either direction. Hiding a row from a
+ * moderator's sidebar must not also bar them from the page behind it, and
+ * un-hiding one must not admit them to a page their role does not carry.
+ *
+ * @param {Array<{items: Array}>} baseNav  the grouped admin nav
+ * @param {string} role
+ * @returns {Array<{to: string, exact: boolean}>}
+ */
+export function allowedPathsFor(baseNav, role) {
+  return (Array.isArray(baseNav) ? baseNav : [])
+    .flatMap((g) => g.items || [])
+    .filter((item) => navItemVisibleTo(item, role))
+    .map((item) => ({ to: item.to, exact: item.end === true }))
+}
+
+/**
+ * Is this pathname one of them?
+ *
+ * A row carrying `end` matches exactly — `/admin` is the dashboard, not a prefix
+ * of the whole admin area, and treating it as one would let every path through.
+ * Every other row also covers its sub-routes, which is what keeps
+ * `/admin/moderation/appeals/12` and a module's detail pages reachable without
+ * anyone listing them.
+ */
+export function isAllowedPath(pathname, allowed) {
+  return (allowed || []).some(({ to, exact }) =>
+    exact ? pathname === to : pathname === to || pathname.startsWith(`${to}/`),
+  )
+}