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]>

docs/development/security.md

@@ -126,6 +126,32 @@ may be published or mounted. A module UI that mounts has gained no privilege it
 — its server half already runs in the API process with the API's database authority — and server APIs
 remain the sole authority for authorization regardless of what a browser loaded.
 
+### The browser host mounts module UI; it grants nothing
+
+Ekklesia's shell (`surfaces/shell`) discovers installed module UIs through
+`GET /api/v1/module-ui` and mounts them with the generic loader
+([ADR 0026](../architecture/decisions/0026-minimal-ekklesia-module-ui-host.md)). Three properties are
+security-relevant.
+
+**The inventory is authenticated, deliberately.** Module UI *bytes* are anonymous because fetching
+compiled code confers no authority, and that route is carefully not an enumeration oracle. The
+inventory is that enumeration — it lists which module products an installation runs — so it requires
+`core.modules.ui.read` (baseline `authenticated`): any signed-in user, and nobody else. It carries no
+filesystem path, package root, or entrypoint.
+
+**Permission hints are computed by the server and remain hints.** For each listed module the API
+evaluates that module's *own* declared permissions against the caller using Core's one authorization
+evaluator, and returns only the granted ids — never a default of `true`, never inferred from a
+client-side role, and never another module's or Core's authorization state. Every module route stays
+enforced by `requirePermission` regardless; the test suite proves it by having a UI that was told
+"denied" call its API anyway and still receive `403`.
+
+**The host executes trusted module code in its own page and does not pretend otherwise.** The loader
+performs a same-origin dynamic `import()` — no `eval`, no `new Function`, no `blob:` URL — and the
+shell owns the container, the loading state, and every error, so a failing module costs its own panel
+rather than the shell. None of that is containment: once imported, a module UI is ordinary same-realm
+JavaScript, exactly as described above.
+
 ### Client-side permission checks are not a security boundary
 
 A host may tell a module UI what permissions it believes the viewer holds