feat: add the minimal operational module lifecycle

Ekklesia had no notion of a module being on or off: the accepted module set
was exactly "whatever discovery found on disk", and `ModuleLifecycleStage`
named nine states nothing produced or consumed. This replaces that vocabulary
with two axes that real code produces — persistent, administrator-owned
configuration (`enabled`/`disabled`) and per-boot runtime observation
(`running`/`disabled`/`blocked`) — and wires them through startup.

- One Core table (`ekklesia_core_module_state`, migration 0004) holding only
  `module_id` and `enabled`. A module with no record is enabled by default, so
  deploying a module is still sufficient to run it and discovery never needs an
  initialization write. A record for an undeployed module is retained and
  ignored, so redeploying restores the decision.
- `resolveModuleEligibility` is pure: a disabled module transitively blocks
  every module that *requires* it (module and capability edges alike) with a
  structured reason naming the provider; optional dependencies never block; and
  a missing, incompatible, or cyclic dependency stays discovery's concern.
- `startApi` starts only the eligible set and builds the UI publication
  registry from that same list, so routes, artifacts, browser inventory, and
  Dashboard navigation all follow one authoritative set. A disabled module is
  never imported, so there is no per-request enablement check anywhere.
- Startup stays all-or-nothing, deliberately; there is consequently no `failed`
  runtime state. `pnpm modules:enable`/`modules:disable` is the out-of-band
  recovery path for a module that breaks startup.
- Changes take effect at the next start, and the read model reports
  configuration, runtime, and `restartRequired` separately rather than claiming
  a module stopped when it has not.
- Migration participation and permission composition still span the deployed
  and discovered inventories respectively, unchanged.
- New restricted platform permission `core.modules.lifecycle.manage` gates both
  reading and changing enablement, at a sibling prefix (`/api/v1/module-lifecycle`)
  that cannot collide with the module route namespace.
- `pnpm doctor` gains a `modules.lifecycle` check so "why is this module
  unavailable?" is answerable without reading logs.

See ADR 0028.

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

docs/architecture/platform-architecture.md

@@ -308,3 +308,24 @@ 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
 scheduled by this document.
+
+Phase 7A pass 1 adds the platform's operational module lifecycle
+([ADR 0028](decisions/0028-module-operational-lifecycle.md)). Core now has two clearly separated
+axes: **configuration** (`enabled`/`disabled`, persistent, administrator-owned, stored in one Core
+table) and **runtime** (`running`/`disabled`/`blocked`, observed per boot). `resolveModuleEligibility`
+is a pure function of the discovered inventory plus that configuration: a module with no stored
+record is enabled by default, an explicit decision always wins, a disabled module transitively blocks
+every module that *requires* it (module and capability edges alike, with a structured reason naming
+the provider), and an optional dependency never blocks anything. `startApi` starts only the eligible
+set and builds the UI publication registry from that same list, so routes, artifacts, browser
+inventory, and Dashboard navigation all follow one authoritative set rather than a filter downstream.
+
+Startup remains all-or-nothing across the eligible set — ADR 0015 and ADR 0020's rollback guarantee
+is unchanged, and there is deliberately no `failed` runtime state, because no live process could
+report one. Enablement is what makes a broken module recoverable, with `pnpm modules:disable` as the
+out-of-band path. Changes take effect at the next start, and the read model reports configuration,
+runtime, and `restartRequired` separately rather than claiming a module stopped when it has not.
+Migration discovery still spans the deployed inventory regardless of enablement, and permission
+composition still spans the whole discovered set. `running` means a module's `start` hook completed
+and nothing more; there is no runtime health-probe contract. Modules remain trusted compiled code —
+disabling one is an operational control, never a sandbox. No installer exists.