feat: add module database ABI v1 adapters

docs/architecture/repository-boundaries.md

@@ -136,11 +136,14 @@ These rules map platform ownership to filesystem and package boundaries. The exe
   declared by the consumer.
 - Code a workspace package ships (its `src/` and `bin/`, excluding tests and declaration files)
   declares every runtime import in `dependencies` or `optionalDependencies`. A peer declaration may
-  stay beside it, but never replaces it: a workspace package is linked into its consumers as a
-  directory, so its imports resolve from its own `node_modules`, where a consumer never satisfies a
-  peer, and a production install (`pnpm install --prod`, as the production image runs) omits
-  development dependencies. Type-only imports are exempt; a `.tsx`/`.jsx` file counts as importing
-  `react`, because the automatic JSX runtime imports `react/jsx-runtime` implicitly
+  stay beside it, but ordinarily never replaces it: a workspace package is linked into its consumers
+  as a directory, so its imports resolve from its own `node_modules`, where a consumer never
+  satisfies a peer, and a production install (`pnpm install --prod`, as the production image runs)
+  omits development dependencies. The one narrow exception is
+  `@ekklesia/module-database`'s `drizzle-orm` peer: modules choose that compatible runtime and the
+  Module Package v1 bundler incorporates it into their self-contained backend; Core never loads the
+  adapter package. Type-only imports are exempt; a `.tsx`/`.jsx` file counts as importing `react`,
+  because the automatic JSX runtime imports `react/jsx-runtime` implicitly
   (`runtime-imports-are-production-dependencies`).
 - Workspace aliases are forbidden because they obscure package ownership in the dependency graph.
 - Workspace package names are unique and shared packages declare a recognized architectural role.