feat: mount discovered module UI in a minimal Ekklesia browser host

Phase 6C pass 2. Every link in the module UI chain existed except the one
that closes it: a module could be authored, built, validated, published at a
browser URL, and loaded by a generic loader — and nothing in Ekklesia did any
of it. There was no browser application at all.

Two pieces were missing. A browser could not discover what to mount, and it
must not work that out for itself.

GET /api/v1/module-ui is the inventory: per publishable module, its id and
version, the server-produced artifact URL, the server-produced root of the
module's own API, and the subset of that module's declared permissions the
caller holds. Five fields, each because building a ModuleUiHostContext needs
it — no filesystem paths, and no name/icon/folder/order, because navigation
metadata is a design that does not exist yet. Its module set is the ADR 0025
publication registry rather than a rescan, so the inventory and the artifact
route cannot disagree. It requires a new Core permission, core.modules.ui.read
(baseline authenticated), because it is precisely the enumeration the anonymous
artifact route deliberately withholds.

Both URLs are server-produced. moduleUiArtifactUrl already existed;
moduleApiBaseUrl is now exported and moduleRoutePath builds on it, so each URL
shape has exactly one author. Without it the shell would hardcode
/api/v1/modules/<id> — the prefix ADR 0022 forbids a module UI from spelling,
reappearing in the host instead.

surfaces/shell (@ekklesia/shell) is the repository's first surface: a small
React application built to static files by its own esbuild script. It resolves
the principal, fetches the inventory, builds the host context entirely from
server-derived data, and hands the artifact URL to @ekklesia/module-ui-host.
One frame per selection — keyed by module identity — defeats the stale-load
race; the host owns the container, the loading state, and every failure, so a
broken module costs its own panel rather than the shell.

The shell statically imports no module, and both levels are checked: no source
import may name a module, and the emitted bundle must contain exactly one
dynamic import (the loader's) with no module id, no /api/v1/modules, no eval,
and no blob URL. Permission hints come from Core's own evaluator and stay
presentation-only — the end-to-end test has a UI holding no grant call its API
anyway and still receive 403.

Surfaces may now depend only on browser-safe shared roles; @ekklesia/contracts
is deliberately excluded, since its barrel pulls Drizzle's types and Node's
globals into the browser — the hole ADR 0024 closed one layer down.

Not the Dashboard: no navigation, grouping, icons, ordering, design system, or
routing. The selector is a list of module ids.

Co-Authored-By: Claude Opus 5 <[email protected]>

core/tests/authorization-permissions.test.ts

@@ -2,6 +2,7 @@ import { parsePermissionId } from "@ekklesia/contracts";
 import { describe, expect, it } from "vitest";
 import {
   CORE_AUTHORIZATION_GRANTS_MANAGE,
+  CORE_MODULES_UI_READ,
   CORE_PERMISSION_DECLARATIONS,
   CORE_PERMISSION_REGISTRY,
   createPermissionRegistry,
@@ -89,8 +90,21 @@ describe("CORE_PERMISSION_REGISTRY", () => {
     expect(declaration?.id).toBe("core.authorization.grants.manage");
   });
 
-  it("contains no other permission in this slice", () => {
-    expect(CORE_PERMISSION_REGISTRY.declarations).toHaveLength(1);
+  it("registers core.modules.ui.read as authenticated, not restricted", () => {
+    const declaration = CORE_PERMISSION_REGISTRY.get(CORE_MODULES_UI_READ);
+    expect(declaration).toBeDefined();
+    // Any signed-in user may learn which module UIs the browser host can mount; a shell that
+    // rendered nothing until an operator granted each user a permission would be unusable, and the
+    // module UIs gate their own content on their own permissions regardless (ADR 0026).
+    expect(declaration?.baseline).toBe("authenticated");
+    expect(declaration?.id).toBe("core.modules.ui.read");
+  });
+
+  it("contains exactly these two permissions and no others", () => {
+    expect(CORE_PERMISSION_REGISTRY.declarations.map((declaration) => declaration.id)).toEqual([
+      CORE_AUTHORIZATION_GRANTS_MANAGE,
+      CORE_MODULES_UI_READ,
+    ]);
   });
 });
 
@@ -102,9 +116,15 @@ describe("CORE_PERMISSION_DECLARATIONS", () => {
         description: "Create, list, and revoke another user's explicit authorization grants.",
         id: CORE_AUTHORIZATION_GRANTS_MANAGE,
       },
+      {
+        baseline: "authenticated",
+        description: "List the installed module UIs a browser host may mount.",
+        id: CORE_MODULES_UI_READ,
+      },
     ]);
     expect(Object.isFrozen(CORE_PERMISSION_DECLARATIONS)).toBe(true);
     expect(Object.isFrozen(CORE_PERMISSION_DECLARATIONS[0])).toBe(true);
+    expect(Object.isFrozen(CORE_PERMISSION_DECLARATIONS[1])).toBe(true);
   });
 
   it("matches exactly what CORE_PERMISSION_REGISTRY exposes as its own declarations, so a composer building on top of it never diverges from what Core itself registers", () => {

core/tests/doctor-report.test.ts

@@ -78,7 +78,7 @@ Modules
   ✓ Dependency graph valid
     Dependency order is empty.
   ✓ Permission registry composed
-    1 permission registered
+    2 permissions registered
 
 Data definitions
   ✓ Schemas validated

core/tests/module-permissions.test.ts

@@ -2,6 +2,7 @@ import { type PermissionBaseline, parseModuleManifest } from "@ekklesia/contract
 import { describe, expect, it } from "vitest";
 import {
   CORE_AUTHORIZATION_GRANTS_MANAGE,
+  CORE_MODULES_UI_READ,
   CORE_PERMISSION_DECLARATIONS,
   PermissionRegistryError,
 } from "../src/authorization/index.js";
@@ -63,9 +64,11 @@ describe("composePlatformPermissionRegistry", () => {
     const registry = composePlatformPermissionRegistry([calendar, people]);
 
     expect(registry.has(CORE_AUTHORIZATION_GRANTS_MANAGE)).toBe(true);
+    expect(registry.has(CORE_MODULES_UI_READ)).toBe(true);
     expect(registry.has("calendar.events.read")).toBe(true);
     expect(registry.has("people.directory.read")).toBe(true);
-    expect(registry.declarations).toHaveLength(3);
+    // Core's own two declarations plus one from each module.
+    expect(registry.declarations).toHaveLength(4);
   });
 
   it("preserves deterministic order: Core first, then modules in the supplied order, then declarations in manifest order", () => {
@@ -81,6 +84,7 @@ describe("composePlatformPermissionRegistry", () => {
 
     expect(registry.declarations.map((declaration) => declaration.id)).toEqual([
       CORE_AUTHORIZATION_GRANTS_MANAGE,
+      CORE_MODULES_UI_READ,
       "calendar.events.read",
       "calendar.events.write",
       "people.directory.read",