feat(module-assembly): add deterministic build-time composition for base and derived application modules #740

Parent epic: #738
Depends on: #739
Related completed foundations: #680, #681, #696

Context

The current trusted registry is a static array in src/modules/index.ts. This is safe for the base repository, but an external derived repository must currently modify or replace that base composition root to register application modules. As the number of derived repositories grows, that approach creates recurring merge conflicts, accidental base edits, migration collisions, and inconsistent capability bindings.

AWCMS-Mini must retain a static, reviewable registry while allowing a derived repository to contribute its own application registry at build time.

Objective

Add deterministic build-time module composition that combines the reviewed base registry, a reviewed application registry, and explicit capability bindings into one final trusted static registry.

Scope

• Introduce a small composition API, such as:
  • listBaseModules();
  • listApplicationModules() or an injected application-registry provider;
  • composeModuleRegistry().
• Keep the default base build behavior unchanged when no application registry is supplied.
• Compose and validate:
  • module keys and descriptors;
  • lifecycle dependency DAG;
  • capability provides/consumes bindings;
  • permission catalogs;
  • navigation descriptors;
  • jobs and health descriptors;
  • migration namespace/range declarations;
  • deployment-profile compatibility metadata.
• Generate a deterministic composed inventory for CI/release evidence.
• Add a minimal external/fixture derived application that contributes at least two modules without editing base src/modules/index.ts.
• Define how a derived repository supplies its registry without runtime discovery, file upload, package scanning, eval, or untrusted code loading.
• Preserve compatibility with module-management sync and existing repository inventory generation.

Security and architecture requirements

• Final registry is static for a built artifact and is produced only from source reviewed in the build.
• Duplicate keys, missing lifecycle dependencies, missing required capabilities, conflicting providers, cycles, and invalid module categories fail before application build.
• Base Core/System modules cannot be replaced or shadowed by an application registry.
• Application modules cannot broaden base permissions or alter another module's descriptor implicitly.
• Offline/LAN builds do not require any network registry or external service.

Out of scope

• Runtime installation/uninstallation of executable modules.
• Public plugin marketplace, arbitrary NPM/Git sources, dynamic imports from tenant input, or code download.
• Implementing derived domain modules in the base repository.

Acceptance criteria

• A derived fixture composes modules without modifying the base registry file.
• A default base build produces the same effective registry as before this change.
• Composition output is deterministic and machine-readable.
• Duplicate module key, missing dependency, lifecycle cycle, missing required capability, conflicting capability provider, and prohibited Core override each fail with actionable diagnostics.
• Permission/navigation/job/health inventories include contributed modules and remain deterministic.
• Module-management sync consumes the composed registry, not an unrelated duplicate source.
• Repository inventory supports base-only and composed-fixture modes without stale generated output.
• Unit tests cover composition and every rejection class.
• At least one integration/build test proves an external fixture can compile and pass module DAG checks.
• Architecture, module-management, derived-app, contributor, and skill documentation are updated.
• bun run modules:dag:check, repository inventory checks, bun run test, bun run build, and bun run check pass.