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]>

packages/contracts/tests/module-manifest.test.ts

@@ -1,8 +1,10 @@
 import { describe, expect, it } from "vitest";
 import {
   isVersionCompatible,
-  MODULE_LIFECYCLE_STAGES,
+  MODULE_BLOCKED_REASONS,
+  MODULE_DEPENDENCY_KINDS,
   MODULE_MANIFEST_VERSION,
+  MODULE_RUNTIME_STATES,
   packageRelativePathSchema,
   parseModuleManifest,
   parsePermissionId,
@@ -341,9 +343,18 @@ describe("module manifest contract", () => {
     expect(isVersionCompatible("not-a-version", "*")).toBe(false);
   });
 
-  it("publishes the complete lifecycle vocabulary", () => {
-    expect(MODULE_LIFECYCLE_STAGES).toContain("discovered");
-    expect(MODULE_LIFECYCLE_STAGES).toContain("failed");
+  it("publishes exactly the operational lifecycle vocabulary the platform implements", () => {
+    // Every name here is produced by real code and observable through the lifecycle read model
+    // (ADR 0028). The nine-stage `MODULE_LIFECYCLE_STAGES` vocabulary this replaced named states
+    // nothing ever entered, including a `failed` state that startup atomicity makes unobservable —
+    // asserting the exact sets is what keeps this contract from drifting back into aspiration.
+    expect(MODULE_RUNTIME_STATES).toEqual(["running", "disabled", "blocked"]);
+    expect(MODULE_RUNTIME_STATES).not.toContain("failed");
+    expect(MODULE_BLOCKED_REASONS).toEqual([
+      "required_dependency_disabled",
+      "required_dependency_blocked",
+    ]);
+    expect(MODULE_DEPENDENCY_KINDS).toEqual(["module", "capability"]);
   });
 
   describe("module-owned UI entrypoint (ADR 0021)", () => {