feat: integrate module authorization

Wires composePlatformPermissionRegistry into apps/api's production
startup: startApi() discovers every installed module, composes the one
immutable platform permission registry (Core's own declarations plus
every module's), and only then constructs the shared PostgreSQL pool,
Better Auth, and the HTTP server. A discovery or composition failure —
an invalid manifest, a reserved core.* namespace claim, or a duplicate
declaration — propagates before anything exists to close; there is no
Core-only registry fallback. apps/api/src/platform-permissions.ts
resolves the repository root from its own file location, never
process.cwd(), so package-scoped test runs discover the right modules/
directory.

createApiApp/createGrantsRoutes now require the composed registry as
an injected authorization option, replacing the previous hard-coded
CORE_PERMISSION_REGISTRY; requirePermission continues to work
identically for Core-owned and module-owned permissions, since it has
no concept of the distinction.

Extends pnpm doctor with a modules.permissions check (reusing the
already-discovered module list, distinguishing reserved-namespace from
generic-duplicate failures, never re-discovering modules) and pnpm
modules:validate to compose the same registry before a module is
considered installable.

Adds focused coverage: startup-ordering and failure-isolation tests in
apps/api/tests/lifecycle.test.ts, module-owned-declaration enforcement
tests in apps/api/tests/authorization-middleware.test.ts, Doctor
composition tests in core/tests/doctor.test.ts, and a live PostgreSQL
end-to-end scenario proving a real installed module's permission is
discoverable, grantable, and deniable once the module is absent again
after a restart, without ever executing its server entrypoint.

docs/module-development/README.md

@@ -121,6 +121,17 @@ every discovered module's declarations, alongside its own, into the one platform
 registry). A duplicate permission id within one manifest, or a permission id outside the module's
 own namespace, fails validation the same way a duplicate or misnamed capability id does.
 
+`apps/api` composes this registry once, at startup, from every module installed at that time (see
+[Authorization](../development/authorization.md#api-startup-discovery-composition-and-enforcement));
+installing, removing, or editing a module's manifest takes effect only on the next API restart, not
+while it is running. Once installed and discovered, a module's declared permission is enforceable
+and grantable through exactly the same mechanism as any Core-owned permission — the same
+`requirePermission` middleware and the same `/api/v1/grants` explicit-grant HTTP API a platform
+owner (or anyone they delegate `core.authorization.grants.manage` to) already uses. Mounting a
+module's own HTTP routes, and creating relationship-derived grants automatically from a module's
+own business logic, are both still later work; this only makes a declared permission *usable*
+through Core's existing, generic surface.
+
 Server and optional schema entrypoints must be compiled ESM `.js` or `.mjs` files. The optional
 migration entrypoint is a directory. All entrypoints begin with `./`, remain inside the package,
 and exist. Production never imports source TypeScript directly. Modules with no tables omit