feat: standalone module-build readiness for the public @ekklesia packages (ADR 0053)

Makes the public module-development package set usable from a module
repository outside the monorepo. Nothing is published.

- Curated @ekklesia/module-sdk: an explicit author API, no contracts
  barrel, no identity/authorization internals, no Drizzle and no legacy
  ModuleDatabase type. defineModuleRuntime returns the SDK's own named
  interfaces so a module's emitted declarations never reach into
  @ekklesia/contracts. defineModuleSchema is gone; createModuleTable and
  defineModuleSchemaMetadata live in @ekklesia/module-database.
- Drizzle: no longer a dependency of module-sdk or contracts. Core keeps
  the legacy Drizzle schema validator (moved to core/src/modules) and
  its legacy runtime support; drizzle-orm is an optional peer only.
- React is a peer (plus devDependency) of @ekklesia/ui; the boundary
  checker allows exactly that consumer-selected peer.
- @ekklesia/typescript-config is publishable; module-ui-host is private.
  Every public package carries "ekklesia.distribution":
  "module-development" and no monorepo-root prepack.
- module-pack reads the Node.js range from the module's own engines.node
  and recognizes Ekklesia packages by name plus that marker, so
  registry-installed packages are incorporated, SDK-compatibility
  checked, and never credited as third-party.
- scripts/pack-public-packages.ts (pnpm packages:pack) rebuilds, packs
  and inspects the nine public tarballs; scripts/test-standalone-module.sh
  (pnpm test:standalone-module, new CI job) installs them into a fixture
  module outside the repository and proves it typechecks, builds,
  packages, and verifies.
- Public-package boundary tests and module-development docs.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/architecture/repository-boundaries.md

@@ -139,10 +139,12 @@ These rules map platform ownership to filesystem and package boundaries. The exe
   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`,
+  omits development dependencies. There are two narrow exceptions, each for one package and one
+  peer. `@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. And `@ekklesia/ui`'s `react` peer (ADR 0053): the shared elements are only
+  ever bundled into browser artifacts, and the consumer's own React must be the one in the bundle;
+  no production Node.js process loads them. 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.