epic: add complete module management for AWCMS-Mini #510

Objective

Add complete, secure, and operational Module Management for AWCMS-Mini.

This epic turns the existing static module registry into a database-backed, tenant-aware module management capability covering module catalog, descriptor sync, lifecycle, dependency validation, tenant enablement, settings, permissions, navigation, jobs, health/readiness, audit, admin UI, OpenAPI/AsyncAPI, and documentation.

Current repo context

AWCMS-Mini already has the core base foundation: Bun, Astro 7, PostgreSQL, tenant, identity, RBAC/ABAC, RLS, audit, sync, workflow, reporting, settings, logging, email, and deployment profile.

Current state:

• src/modules/index.ts registers 9 modules.
• ModuleDescriptor is still minimal.
• awcms_mini_modules already exists from migration 001.
• Latest migration is currently 024_awcms_mini_email_message_cancel_permission_schema.sql.
• The next module management migration must start from 025_awcms_mini_module_management_schema.sql.
• Email module is now 0.5.0 and includes template management, password reset, announcement, observability, suppressions, cancel, provider health, and events.
• Admin navigation is still hardcoded in AdminLayout.astro.

Scope

• Add module_management as a base enhancement module.
• Extend module descriptor metadata.
• Add database-backed module registry/state using migration 025.
• Sync trusted code descriptors into database registry.
• Manage tenant module enablement/disablement safely.
• Enforce dependency graph validation.
• Manage tenant-aware non-secret module settings.
• Integrate module permissions.
• Add dynamic admin navigation registry.
• Register module jobs/commands.
• Add module health/readiness checks.
• Add admin UI under /admin/modules.
• Add audit events for lifecycle/config/high-risk actions.
• Update OpenAPI, AsyncAPI if lifecycle events are published, ERD, SOP, threat model, tests, and changeset.

Out of scope

• Runtime upload/install of arbitrary third-party code.
• Marketplace.
• Remote module repository.
• Dynamic import from untrusted paths.
• Rebuilding tenant/auth/RBAC/ABAC/RLS/audit/sync/workflow/email foundations.
• Breaking or repurposing existing /api/v1/access/modules.

Security notes

• Default deny.
• Tenant-scoped tables must use tenant context, ABAC, and RLS.
• High-risk actions must be audited.
• Module secrets must remain in environment variables or deployment secret managers.
• Sensitive settings must be redacted in logs, API responses, and audit attributes.
• Disabling a module must not delete tenant data.
• Core/system modules must not be tenant-disableable.
• Provider checks must not block critical transaction paths.
• Align with OWASP ASVS, OWASP API Security Top 10, ISO/IEC 27001, 27002, 27005, 27701, 22301, UU PDP, PP PSTE, and UU ITE.

Proposed child issues

1. Extend module descriptor contract.
2. Add module management schema and permission seed.
3. Scaffold module_management module and descriptor sync service.
4. Add module catalog/read API.
5. Add tenant module lifecycle API with dependency validation.
6. Add module settings management.
7. Add module permission sync/status.
8. Add module navigation registry and admin layout integration.
9. Add module job registry.
10. Add module health/readiness checks.
11. Add admin UI for Module Management.
12. Update docs, OpenAPI/AsyncAPI, tests, threat model, and changeset.

Acceptance criteria

• All registered modules can be listed from code and database.
• Module registry sync is idempotent.
• Tenant module enable/disable works safely.
• Dependency validation blocks unsafe lifecycle actions.
• Module settings can be managed without storing secrets in DB.
• Admin navigation can be provided by modules and filtered by permission.
• Health/readiness is available per module.
• Existing module behavior remains backward-compatible.
• bun run check passes.