feat: one generic image, with installed modules in installation-owned storage (ADR 0048)

The production image now contains zero feature modules and is the same for every
installation. Installed modules live in module storage that one Core resolver
selects from EKKLESIA_MODULES_DIR: the checkout's modules/ when unset, an
absolute path that must exist when set (/var/lib/ekklesia/modules in the image).
A relative, blank, missing, or unreadable configured directory fails closed with
a sanitized error that never contains the value.

- Host configuration reads EKKLESIA_MODULES_DIR. The API, migration plan, apply
  and validate, module validation, module enablement, and Doctor all resolve it
  the same way; the test-only API override still takes precedence.
- Doctor receives Core's migrations directory explicitly instead of deriving it
  from the modules directory's parent.
- The migration runner retains and reports the applied history of a module that
  is not installed, and plans and applies Core's and present modules' migrations
  around it. Core's history and every installed module's history stay strict: a
  missing or changed applied migration, or a downgrade, still fails. No down
  migrations, no data deletion.
- deploy/Dockerfile copies no module and installs nothing for the module
  template; .dockerignore excludes modules/ and the build refuses a context that
  contains it; the runtime has an empty root-owned /var/lib/ekklesia/modules and
  sets EKKLESIA_MODULES_DIR.
- deploy/compose.yaml bind-mounts EKKLESIA_MODULES_HOST_DIR read-only into api
  and migrate, with create_host_path disabled.
- scripts/check-image.sh proves the image holds no modules and that a populated
  modules/ directory leaves its runtime file system identical; CI runs it.
- The split deploy smoke now uses the same generic image: it boots with no
  modules, installs a self-contained test module packaged from the template
  (test-only), migrates and restarts, removes it (Core runs, planning reports the
  retained history, data survives), and restores it with its data.

Docs: deploy README (module storage, install/update/remove/restore, the runtime
modules target), .env.example, API configuration, module development guide,
testing, workflow, security, and the architecture overview.

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

docs/development/repository-workflow.md

@@ -35,8 +35,10 @@ The lint, typecheck, and test commands run both repository-root checks and every
 package-level Turborepo task. New packages add their own `lint`, `typecheck`, and `test` scripts;
 the root verification command discovers them automatically.
 
-`pnpm modules:validate` builds the workspace, then scans `modules/*` without a central registry. A
-missing or empty modules directory is valid and reports zero installed modules. Installed modules
+`pnpm modules:validate` builds the workspace, then scans the installed-modules directory without a
+central registry: the checkout's own `modules/`, or `EKKLESIA_MODULES_DIR` when it is set (ADR
+0048). A missing or empty `modules/` is valid and reports zero installed modules; a configured
+directory must exist. Installed modules
 must produce the compiled JavaScript entrypoints declared by their static manifests. Each module's
 declared browser contributions are listed with their target capability and range, and marked
 according to whether a compatible provider is installed — a contribution nobody provides is otherwise
@@ -113,9 +115,12 @@ identity secret, not a module secret value.
 
 Every check has a stable ID and one of four states: pass, warning, failure, or skipped. Independent
 checks continue after a failure; a failed prerequisite causes only its dependent checks to be
-skipped. Pending or approval-blocked migrations are warnings and are never applied. Invalid
-history, checksum disagreement, unknown applied migrations, or a failed configured connection are
-failures. If `DATABASE_URL` is missing, PostgreSQL is skipped and all static checks still run.
+skipped. Pending or approval-blocked migrations are warnings and are never applied. Applied
+history that belongs to a module which is not installed is reported as `retained` and is neither a
+warning nor a failure (ADR 0048). Invalid history, checksum disagreement, an applied migration that
+an installed module or Core no longer contains, or a failed configured connection are failures. An
+unusable configured `EKKLESIA_MODULES_DIR` fails module discovery. If `DATABASE_URL` is missing,
+PostgreSQL is skipped and all static checks still run.
 
 `READY` means every check passed. `READY WITH WARNINGS` means no check failed but at least one check
 warned or was skipped. Both results exit zero. `NOT READY` means at least one check failed and exits