feat: establish core identity foundation

Adds Core-owned identity contracts, a Core-owned Better Auth database schema
(ekklesia_core_user/session/account/verification), a first-class Core-owned
migration source that coexists with module-owned migrations under the exact
existing migration system, and an explicit Better Auth construction boundary.
No authentication endpoint or sign-in UI is exposed yet (ADR 0010).

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

CLAUDE.md

@@ -0,0 +1,86 @@
+# CLAUDE.md
+
+Guidance for Claude Code (and other coding agents) working in this repository. This file is
+intentionally short and durable — it points at authoritative sources instead of restating their
+contents, because restated details drift.
+
+## What this repository is
+
+Ekklesia is a modular, self-hosted church platform built as a strictly layered pnpm/TypeScript
+monorepo:
+
+- **Core** (`core/`) owns platform infrastructure: identity, database connectivity, migration
+  execution, module discovery/lifecycle, and other feature-agnostic services. Core never imports a
+  feature module, a surface, or an app.
+- **Modules** (`modules/*`, template at `templates/module`) are backend-only capability packages.
+  They own their own data and migrations, declare capabilities/permissions through
+  `@ekklesia/contracts` and `@ekklesia/module-sdk`, and must never contain UI or import Core,
+  another module, or a surface directly.
+- **Surfaces** (future `surfaces/*`) own all UI and presentation. They consume public API/client
+  contracts only, never Core or module internals directly.
+
+These boundaries are enforced by `pnpm boundaries` (`scripts/check-boundaries.ts`), not just
+documented. Read `docs/architecture/repository-boundaries.md` and
+`docs/architecture/platform-architecture.md` before proposing any change that crosses a layer.
+
+## ADRs are authoritative
+
+`docs/architecture/decisions/` records durable architectural decisions. **Accepted ADRs are
+immutable except for status and cross-reference corrections** — do not edit their content to fit a
+new change. A changed decision gets a new ADR that supersedes the old one. Read the full ADR index
+(`docs/architecture/decisions/README.md`) and every ADR relevant to the area you are touching
+before designing a change; do not assume this file's summary of any decision is complete or
+current.
+
+## Read before you design
+
+At minimum, read the current versions of:
+
+- `docs/architecture/decisions/README.md` and every ADR relevant to your change
+- `docs/architecture/platform-architecture.md` and `docs/architecture/repository-boundaries.md`
+- `README.md` (current platform status — what is and is not implemented)
+- `docs/development/repository-workflow.md` and `docs/development/testing.md`
+- `CONTRIBUTING.md`
+
+These files change as the platform evolves. **Inspect the actual current repository state
+(source, tests, package.json scripts, CI workflow) before relying on anything in this file or in
+your own memory of a prior session** — treat stale assumptions as a bug to catch, not a shortcut.
+
+## Working conventions
+
+- Work on a clean branch off an up-to-date `main`; never commit or push directly to `main`; never
+  change branch-protection settings.
+- Keep PRs focused on one bounded slice. Record major architectural changes in an ADR rather than
+  burying them in an implementation.
+- Add or update tests when you change a contract or architectural rule. New behavior needs new
+  test coverage, not just a passing existing suite.
+- Errors that reach a user, log, CLI, or `pnpm doctor` output must be sanitized: never expose
+  secrets, connection strings, raw SQL, raw driver/exception messages, stack traces, causes, or
+  machine-specific paths. Match the sanitization pattern already used by
+  `core/src/migrations/runner.ts` and `core/src/diagnostics/doctor.ts` rather than inventing a new
+  one.
+- Never run a database migration automatically (on import, on startup, in a test that isn't
+  explicitly a migration test, or as a side effect of an unrelated command). Migrations are always
+  an explicit, operator-invoked action.
+
+## Canonical verification commands
+
+Run from the repository root; `package.json` is the source of truth if this list and the file
+ever disagree:
+
+- `pnpm verify` — the full code-only gate (format, lint, boundaries, typecheck, tests, module and
+  migration validation, identity schema drift check, build). Docker-free; never touches a live
+  database.
+- `pnpm test:migrations:integration` — live, disposable-PostgreSQL migration evidence. Requires
+  Docker. Run this for any change touching migration discovery, planning, or execution.
+- `pnpm doctor` — read-only local readiness report. Never treat it as a substitute for `pnpm
+  verify` or the integration suite.
+- `pnpm migrations:plan` / `pnpm migrations:apply` — read-only planning vs. mutating execution
+  against `DATABASE_URL`. Never run `migrations:apply` without the user's explicit intent.
+
+## When you're unsure
+
+If a task would require weakening an existing ADR's guarantee, introducing a second mechanism
+where one already exists (a second migration runner, a second discovery path, a second config
+system), or exposing something the boundary checker currently blocks, stop and surface the
+conflict instead of working around it.