docs: document module database access

Add ADR 0016 recording the accepted module database access design (ModuleDatabase, the frozen
ModuleRuntimeServices boundary, one pool/one facade/one services-object identity, explicit
migrations, and the trust model), with narrow cross-reference corrections to ADR 0006 and ADR 0015
where their original text is now inaccurate. Sweep docs/development/api.md,
docs/development/authorization.md, docs/module-development/README.md, docs/development/testing.md,
and docs/development/identity.md for the new database boundary and remaining Phase 4C staleness;
correct the stale "Phase 4C is next" roadmap paragraph in platform-architecture.md and the matching
gap in README's current-status narrative. Extend the module template with a permissioned
GET /records route reading through context.services.database, using the canonical
createModuleTable helper, with matching template tests.

docs/architecture/platform-architecture.md

@@ -95,12 +95,29 @@ identical lowest-privilege baseline status, and signup order never grants elevat
 [ADR 0011](decisions/0011-identity-http-transport-and-public-enrollment.md) and
 [the API guide](../development/api.md), and
 [the identity development guide](../development/identity.md) for the underlying schema and
-contracts. It is now possible to publicly register, sign in, resolve a principal, and sign out; it
-is not yet possible to verify an email, recover a password, reach a Dashboard, or hold any role or
-permission.
+contracts. It is now possible to publicly register, sign in, resolve a principal, and sign out.
 
-The next architectural phase is Phase 4C: Core authorization (public / authenticated-baseline /
-relationship-derived / grants / platform-owner) and an explicit, auditable platform-owner bootstrap
-command. Other target architecture not yet implemented includes production approval-provider
-composition, physical storage-bucket provisioning, Surface SDK, richer public resource and action
-contracts, dashboard, Builder, and reference feature modules.
+Phase 4C is complete: Core's authorization foundation — a schema, evaluator, and store for
+platform owners, explicit grants, and relationship-derived grants, plus an immutable permission
+registry — and an explicit, single-use, auditable platform-owner bootstrap command, plus reusable
+Hono enforcement and an `/api/v1/grants` HTTP API in `apps/api`. See
+[ADR 0013](decisions/0013-core-authorization-and-owner-bootstrap.md) and
+[the authorization guide](../development/authorization.md).
+
+Phase 5A wired module-declared permissions into that same authorization system — a version-3
+manifest, one composed platform permission registry spanning Core's own declarations and every
+installed module's, enforced through the identical middleware Core's own routes use. Phase 5B let a
+module mount its own framework-neutral HTTP routes in production, under
+`/api/v1/modules/<module-id>`, enforced and response-sanitized exactly like Core's own routes. This
+branch completes Phase 5C: typed module database access (`context.services.database`) for a
+module's lifecycle hooks and authorized HTTP handlers, over the platform's one existing PostgreSQL
+pool. See [ADR 0014](decisions/0014-module-permission-declarations-and-platform-registry.md),
+[ADR 0015](decisions/0015-static-module-http-routing-and-runtime-lifecycle.md),
+[ADR 0016](decisions/0016-module-database-access.md), and the repository root
+[README](../../README.md#current-status) for the complete, current status of every phase.
+
+The project continues finishing the module platform's backend foundations before Phase 6 Surface
+work begins. 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.