feat: define the module UI authoring model and host contract

ADR 0021 established that a module may own UI and added a statically
validated, never-executed `entrypoints.ui` path, but deliberately left
five questions open: what the artifact exports, what a host provides,
how one artifact runs under both Ekklesia and a standalone host, what
the browser-side trust model is, and how module UI avoids being welded
to a Dashboard that does not exist. This answers them.

React and TypeScript are the supported module UI authoring model. The
repository already leaned this way: `packages/typescript-config` ships a
`browser.json` preset and a `react-native.json` preset with
`"jsx": "react-jsx"`, and ADR 0002 names browser and React Native
configurations. One framework is supported; every other stays rejected.

React is deliberately not part of the contract. A module's compiled
artifact default-exports `defineModuleUi({ id, version, mount })`, and
`mount(container, context)` takes a DOM element and returns an unmount
function. `id` and `version` are build-artifact identity markers a host
verifies against the manifest, mirroring `defineModuleRuntime` exactly.
A host needs an element and a context, never a matching rendering
library, so a module's framework, a host's framework, and the platform
boundary between them stay independent.

The contract lives in a new `@ekklesia/module-ui-sdk` rather than in
`@ekklesia/module-sdk`, for a concrete reason: that package re-exports
all of `@ekklesia/contracts`, so routing module UI through it would drag
Zod, Drizzle, and semver into every browser bundle. The new package has
no runtime dependencies, and its one dependency on contracts is
type-only — the emitted `host-context.js` is `export {};`, and a test
pins that so it cannot regress.

The host context is four members: `moduleId`, `api`, `principal`, and
`permissions`. Navigation, theme, module configuration, organization
context, and diagnostics are deliberately absent; each needs a design
that does not exist. Module UI reaches its backend through
`api.request(path)` with a path relative to its own API root and never
constructs `/api/v1/modules/<id>/...`, which is Ekklesia's private
deployment detail — a module that builds that URL is silently unhostable
anywhere else. One fixture artifact is mounted under two hosts with
different origins and URL shapes to prove it.

Client-side permission hints are presentation only, and both the docs
and a test say so plainly: a denied hint does not stop the module from
calling its API, because server-side `requirePermission` is the only
authority. Module UI is trusted code in the host's own browser realm —
no iframe, no sandbox — which matches the backend model rather than
overstating it, since a module's server half already holds the API's
database authority.

The boundary guard is narrowed precisely, not removed: `.tsx`, `react`,
and `react-dom` are un-denied and modules may depend on the new
`module-ui-sdk` role. `.jsx`, `.css`, every other framework,
`react-router-dom`, `react-native`, and `@vitejs/plugin-react` stay
denied, layer rules are untouched, and an unsupported framework aliased
behind an allowed name (`"react": "npm:vue@3"`) is resolved and rejected
by its real target. Fixtures prove each case, including that module UI
source still cannot import Core.

Core, apps/api, and the manifest contract are untouched. Discovery still
validates the `entrypoints.ui` path and never evaluates it; hosts
perform their own dynamic import and validate the result with
`parseModuleUiExport`. No Dashboard shell, UI runtime, navigation,
grouping, standalone host, build or styling pipeline, installer,
hot-loading, or feature module is added.

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

README.md

@@ -218,7 +218,7 @@ development proceeds under the current trusted-contributor, not-yet-deployed mod
 and job-token authority remain unverified and are not described as isolated. See
 [Security model and deployment trust boundaries](docs/development/security.md).
 
-Phase 6A establishes the **module product contract** and nothing else yet. Ekklesia's modules are no
+Phase 6A established the **module product contract**. Ekklesia's modules are no
 longer backend-only capability packages: a module is an independently versioned *product* that owns
 its domain behavior, data, permissions, routes, migrations, and — new in this pass — **its own UI**.
 Core keeps the containing application shell and every platform policy (authentication, authorization
@@ -230,18 +230,43 @@ never a dependency. The long-term goal is one module implementation hosted by Ek
 by a standalone application — never two codebases for one domain. See
 [ADR 0021](docs/architecture/decisions/0021-modules-as-hostable-products.md).
 
-**What this pass actually ships is the static contract only.** `manifestVersion: 4` adds one
+**What that pass shipped is the static contract only.** `manifestVersion: 4` adds one
 optional field, `entrypoints.ui`, a package-relative path to a compiled ESM artifact validated
 during discovery exactly like `server` and `schema` — inside the package, real file, no source
 TypeScript. Discovery stays inert: **nothing imports, mounts, or renders that entrypoint**, exactly
 like the long-declared `entrypoints.jobs`. Upgrading a backend-only version 3 manifest is a
 one-character edit; version 3 is rejected outright rather than reinterpreted, as version 2 was
-before it. **The Dashboard shell, a UI runtime or renderer, any UI framework choice, navigation
+before it. **The Dashboard shell, a UI runtime or renderer, navigation
 registration, Dashboard grouping, a standalone host, a module installer or marketplace, hot-loading,
-and every feature module do not exist.** `pnpm boundaries` also still enforces
-`modules-do-not-own-ui`, so module UI cannot yet be authored with a UI framework — choosing that
-authoring model is the next pass's first question. Restart-based discovery, explicit
-operator-invoked migrations, and the trusted compiled-module model are unchanged.
+and every feature module do not exist.** Restart-based discovery, explicit operator-invoked
+migrations, and the trusted compiled-module model are unchanged.
+
+Phase 6B pass 1 answers the question Phase 6A deliberately left open: **what a module UI actually is,
+and what a host gives it.** Module UI is authored in **React and TypeScript**, and a module package
+may now contain `.tsx` and depend on `react`/`react-dom` — every other UI framework stays rejected by
+`pnpm boundaries`, and the layer rules are untouched, so module UI still cannot import Core, an app,
+a surface, or another module. React is the supported *authoring* model but is deliberately **not** in
+the contract: a module's compiled `entrypoints.ui` artifact default-exports
+`defineModuleUi({ id, version, mount })`, and `mount(container, context)` receives a DOM element and
+returns an unmount function. A host needs an element and a context, never a matching framework.
+
+The new `@ekklesia/module-ui-sdk` package (no runtime dependencies; its one dependency on
+`@ekklesia/contracts` is type-only) carries that contract for module authors and hosts alike. The
+host context is deliberately four members — `moduleId`, `api`, `principal`, `permissions` — and
+nothing else. **A module UI asks its host for its own API by relative path** (`api.request("posts")`)
+and never constructs `/api/v1/modules/<id>/...`, which is Ekklesia's private deployment detail; that
+one rule is what keeps a future standalone host possible, and the test suite proves it by mounting
+one fixture artifact under two hosts with different origins and URL shapes. **Client-side permission
+hints are presentation only** — server-side `requirePermission` remains the sole authority — and
+**module UI is trusted code in the host's own browser realm**: no iframe, no sandbox, matching the
+backend trust model rather than pretending to improve on it. See
+[ADR 0022](docs/architecture/decisions/0022-module-ui-authoring-and-host-contract.md).
+
+**This is a contract, not a running feature.** No Dashboard mounts a module UI, no module ships one,
+and the pipeline that compiles a module's `.tsx` into the compiled artifact is not designed —
+`.css` and bundler plugins stay rejected for that reason. Core still never loads browser code:
+discovery validates the `entrypoints.ui` path and never evaluates it, and hosts do their own dynamic
+import.
 
 **Security model.** Installed modules are trusted compiled backend code that runs arbitrary
 JavaScript in the API process and shares its PostgreSQL role — table prefixes, manifests, permission