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/development/authorization.md

@@ -111,7 +111,7 @@ below to build on without reconstructing Core's own list:
 
 ## Module permission composition
 
-A module manifest's `permissions` array (`manifestVersion: 3`,
+A module manifest's `permissions` array (`manifestVersion: 4`,
 [Module development](../module-development/README.md#canonical-manifest)) declares permissions in
 the exact same `PermissionDeclaration` shape — but declaring one there only proves it is
 well-formed and correctly namespaced under the module's own id; it does not, by itself, register
@@ -593,7 +593,7 @@ module database usage), and exactly one `pool.end()` call regardless of how many
 - `packages/contracts/tests/authorization.test.ts` — `PermissionDeclaration` shape validation:
   every baseline, unknown-property/missing-baseline/invalid-baseline/blank-or-oversized-description
   rejection, malformed permission id rejection.
-- `packages/contracts/tests/module-manifest.test.ts` — `manifestVersion: 3` acceptance and version
+- `packages/contracts/tests/module-manifest.test.ts` — `manifestVersion: 4` acceptance and version
   2/string-array rejection, per-declaration validation (mirroring the contracts-level cases above),
   module-namespace enforcement, duplicate permission id at its exact `permissions[index].id` issue
   path, and default-empty-list isolation across separate parses.

docs/development/security.md

@@ -53,6 +53,13 @@ cooperative. None of them constrains a module that is not:
 schema-permission, table-ACL, row-level-security, tenant, or resource sandbox between a module and
 Core.** A module is not isolated from Core, from other modules, or from the host.
 
+[ADR 0021](../architecture/decisions/0021-modules-as-hostable-products.md) lets a module declare its
+own UI entrypoint. **That changes nothing on this page.** A module that ships UI is exactly as
+trusted as one that does not: its server entrypoint still runs in the API process with the authority
+described above, and declaring `entrypoints.ui` neither adds nor implies any isolation. No host
+loads a UI entrypoint yet; when one does, the trust model for whatever it executes must be decided
+explicitly and recorded — it does not inherit a boundary from this section, because none exists.
+
 ## What this platform must not claim
 
 Ekklesia today has **none** of the following, and no document, README, or marketing surface may