docs: define deployment trust boundaries

One canonical security document, linked from the README, platform architecture,
and module-development guide, stating what the boundaries actually protect
against — and, more importantly, what they do not.

Installed modules are trusted compiled backend code. A module runs arbitrary
JavaScript inside the API process and shares its PostgreSQL role and pool, so
`ModuleDatabase.execute` gives it the API's full database authority over every
table, including identity, grants, owner, bootstrap, and audit. Table prefixes,
manifests, permission declarations, route validation, frozen contexts, typed
facades, and the capability registry are correctness and coordination boundaries
that assume a cooperative module; none of them constrains one that is not. There
is no process, container, syscall, filesystem, network, database-role, schema,
tenant, or resource sandbox between a module and Core, and the document says so
in those words, along with what would have to be built before untrusted modules
could be accepted.

It also records the honest deployment state: Ekklesia is not deployed. There is
no production instance, reverse proxy, public listener, or deployment automation
anywhere in this repository, and no `.env` has ever been committed. The loopback
listen default and the production signup refusal are real, but a config default
is not a firewall, so the origin-reachability, proxy-overwrite, header-spoofing,
and trusted-peer properties a public launch needs are written as a
launch-blocking checklist rather than as guarantees. The per-process
authentication limiter is described as exactly that, valid only while signup
stays disabled and exactly one instance serves traffic.

The CI section records the workflow's verified posture and deliberately stops
there: a pull request can edit `runs-on`, so a workflow file cannot be the
boundary, and the runner topology is not described as though it had been
verified.

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

README.md

@@ -189,6 +189,15 @@ exists. Modules remain trusted compiled backend code with no process, role, sche
 isolation. Phase 5D is still not complete** — pass 5 (deployment/supply chain plus an independent
 whole-repository re-audit) remains outstanding, and Phase 6 remains blocked.
 
+**Security model.** Installed modules are trusted compiled backend code that runs arbitrary
+JavaScript in the API process and shares its PostgreSQL role — table prefixes, manifests, permission
+declarations, typed facades, and frozen contexts are correctness boundaries, not a sandbox. Ekklesia
+is also **not currently deployed**: there is no production instance, reverse proxy, public listener,
+or deployment automation, so the origin/proxy/throttling properties a public launch requires are
+unproven launch-blockers rather than existing guarantees. Read
+[Security model and deployment trust boundaries](docs/development/security.md) before installing a
+module or exposing the API.
+
 ## Quick start
 
 Prerequisites: Node.js 24 LTS, pnpm 11.12, and Docker with Compose.