feat: establish the module product contract

Ekklesia's module model has been backend-only since ADR 0001: a module
owns domain behavior and data, and every presentation concern belongs to
a surface. That prevents a module author — the person who knows the
domain — from shipping the screen that makes their module useful, and it
guarantees a module and its own UI drift apart. It also pushes toward two
codebases for one domain the moment a module needs to run standalone.

ADR 0021 replaces that rule. A module is an independently versioned
product that owns its domain behavior, data, permissions, routes,
migrations, and its own UI, hostable inside Ekklesia and — from the same
implementation — by a later standalone host. Core keeps the containing
application shell and every platform policy: authentication,
authorization enforcement, platform context, top-level routing,
navigation, global theme, error boundaries, and trusted-origin/CORS. The
module graph stays flat: modules are peers, genuine module and capability
dependencies remain the only relationships, and Dashboard folders are
presentation configuration an administrator can reorganize, never module
architecture.

This pass implements the static contract only. `manifestVersion` moves to
4 and `entrypoints` gains one optional field, `ui`. Version 3's
`entrypoints` is strict and rejects `ui`, so this is an incompatible
shape change and version 3 is now rejected outright rather than
reinterpreted, exactly as version 1 was by version 2 and version 2 by
version 3. Every field version 4 adds is optional, so upgrading a
backend-only manifest is a one-character edit.

Discovery resolves and validates `ui` under the same rules as `server`
and `schema` — package-relative, inside the package before and after
symlink resolution, a real file, compiled ESM `.js`/`.mjs`, so source
TypeScript is rejected rather than assumed to be compiled later.
Discovery stays inert: nothing imports, evaluates, mounts, or renders a
UI entrypoint, and a test proves a throwing artifact still discovers
successfully. This follows `entrypoints.jobs`, declared and resolved
since ADR 0006 with no runtime consumer.

The name is `ui`, not `dashboard`, because a module's UI must be hostable
by Ekklesia's shell and by a standalone host, so the contract cannot be
named after one of them; and not `surface`, because `surfaces/*` is a
separate ownership layer. No widget, route, icon, folder, menu, layout,
or standalone-metadata field is added, and tests assert the manifest
still rejects every unknown entrypoint key and offers no hierarchy field.

Deliberately unchanged: `scripts/check-boundaries.ts` still enforces
`modules-do-not-own-ui`. Relaxing that guard depends entirely on the UI
authoring model a later pass chooses, and weakening a working protection
before that decision exists would trade real coverage for nothing. A
module may therefore declare `ui` today only for a framework-neutral
compiled artifact, and the docs say so rather than implying otherwise.
Restart-based discovery, explicit operator-invoked migrations, and the
trusted compiled-module model are untouched — a module that ships UI is
exactly as trusted as one that does not.

No Dashboard shell, UI runtime, renderer, framework choice, navigation
registry, grouping system, standalone host, installer, hot-loading, or
feature module is added by this pass.

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

docs/architecture/platform-architecture.md

@@ -4,10 +4,12 @@ Ekklesia is a long-lived platform from which churches can compose many applicati
 experiences. It begins as a modular monolith so contracts can stabilize before distribution is
 introduced.
 
-> **Trust boundary.** Installed modules are trusted compiled backend code, not sandboxed
-> plugins: a module runs arbitrary JavaScript in the API process and shares its PostgreSQL
-> role. The layering described below is a correctness and ownership boundary, not hostile-code
-> isolation. See [Security model and deployment trust boundaries](../development/security.md).
+> **Trust boundary.** Installed modules are trusted compiled code, not sandboxed plugins: a module
+> runs arbitrary JavaScript in the API process and shares its PostgreSQL role. The layering
+> described below is a correctness and ownership boundary, not hostile-code isolation. A module that
+> ships its own UI ([ADR 0021](decisions/0021-modules-as-hostable-products.md)) is exactly as
+> trusted as one that does not. See
+> [Security model and deployment trust boundaries](../development/security.md).
 
 ## Dependency model
 
@@ -27,16 +29,26 @@ The four ownership layers are:
 
 1. **Core** orchestrates generic platform infrastructure: startup, identity, permissions,
    configuration, database connectivity, storage, events, jobs, module discovery, and lifecycle.
-2. **Modules** own backend domain behavior, data schemas, resources, actions, routes, events,
-   permissions, and jobs.
-3. **Surfaces** own every presentation concern: components, renderers, layout, navigation,
-   accessibility, interaction, branding, and client state.
+2. **Modules** own domain behavior, data schemas, resources, actions, routes, events, permissions,
+   jobs — and, per [ADR 0021](decisions/0021-modules-as-hostable-products.md), their own UI. A module
+   is an independently versioned product, not only a backend capability. It does not own the
+   containing application shell or any platform policy.
+3. **Surfaces** own the presentation concerns a module does not: the containing application shell,
+   layout, navigation, accessibility, interaction, branding, and client state — including the shell
+   that hosts a module's own UI.
 4. **Surface Builder** stores validated declarative composition. It selects capabilities and
    surface-owned renderers but contains neither executable code nor module business logic.
 
-Modules do not own UI. For example, Calendar data, actions, and permissions will live in
-`modules/calendar`; Calendar renderers for a dashboard or public website will live in those
-surfaces.
+A module owns its own product experience. Calendar data, actions, permissions, and its own
+management UI live in `modules/calendar`; the dashboard or public-website shell that hosts it —
+navigation, theme, layout, and platform chrome — lives in a surface. The module supplies the screen
+for its feature; the surface supplies the application around it.
+
+Modules are flat peers. `video`, `livestream`, `announcements`, and `calendar` are independent
+first-class modules with no parent/child relationship. A Dashboard may group them into folders such
+as `Media` or `Sunday Production`, but those groups are presentation configuration an administrator
+can reorganize, never module ownership and never a dependency. Genuine module and capability
+dependencies remain the only way one module may require another.
 
 ## Stable seams
 
@@ -151,7 +163,21 @@ blocks Phase 6. Read
 does and does not protect against, and the repository root
 [README](../../README.md#current-status) for the current status of every phase.
 
-The module platform's backend foundations are now in place and Phase 6 Surface work is unblocked.
+**Phase 6A establishes the module product contract.**
+[ADR 0021](decisions/0021-modules-as-hostable-products.md) replaces the backend-only module model:
+a module is an independently versioned product that may own its own UI, hostable inside Ekklesia and
+— later, from the same implementation — as a standalone application. Core keeps the host shell and
+every platform policy, the module graph stays flat, and Dashboard grouping stays presentation
+configuration.
+
+What this pass actually implements is the **static contract only**: `manifestVersion: 4` adds one
+optional `entrypoints.ui` field, validated during discovery exactly like the server and schema
+entrypoints — package-relative, inside the package, compiled ESM. Discovery remains inert; nothing
+imports, mounts, or renders that entrypoint. The Dashboard shell, the UI runtime, the standalone
+host, module UI authoring (including the still-enforced `modules-do-not-own-ui` boundary rule), and
+every feature module remain future work. Restart-based discovery, explicit operator-invoked
+migrations, and the trusted compiled-module model are all unchanged.
+
 Target architecture not yet implemented includes production approval-provider
 composition, physical storage-bucket provisioning, jobs/workflow automation, richer public resource
 and action contracts, a Dashboard, a Builder, and reference feature modules; none of these are