feat: define module database access

Introduce ModuleDatabase (a typed, restricted Drizzle query surface) and the frozen
ModuleRuntimeServices boundary in @ekklesia/contracts, and thread the same services object
through Core's module start/stop lifecycle hooks and apps/api's authorized module HTTP handler
context. apps/api builds the facade via a new core/src/modules/database.ts view (createModuleDatabaseView)
over the one existing shared PostgreSQL pool, alongside the identity and authorization views, and
wires it into startApi's fixed startup order ahead of Identity/Authorization construction.
Registration stays database-free; a module reaches its database only through an authorized start,
stop, or HTTP handler invocation.

packages/contracts/src/module-runtime.ts

@@ -1,5 +1,6 @@
 import type { CapabilityId, ModuleId } from "./identifiers.js";
 import { moduleIdSchema } from "./identifiers.js";
+import type { ModuleRuntimeServices } from "./module-database.js";
 import type { ModuleHttpRouteRegistrar } from "./module-http.js";
 import { semanticVersionSchema } from "./versions.js";
 
@@ -29,9 +30,14 @@ export interface ModuleRegistrationContext {
   readonly moduleId: ModuleId;
 }
 
+/** The same context shape for both `start` and `stop`: whichever hook runs, it receives the exact
+ * same frozen `services` object identity as the other, for a given API runtime — never a fresh
+ * `ModuleRuntimeServices` built per hook invocation. Unlike `ModuleRegistrationContext`, this never
+ * carries `http`: a route can only ever be declared during `register`. */
 export interface ModuleRuntimeContext {
   readonly capabilities: CapabilityResolver;
   readonly moduleId: ModuleId;
+  readonly services: ModuleRuntimeServices;
 }
 
 export interface ModuleRuntimeDefinition {