feat: verify email addresses and recover forgotten passwords

Ekklesia could authenticate a person and, since Pass 1, send a
transactional email — but it had no way to establish that an address
belonged to whoever claimed it, and no way back in for someone who
forgot their password.

A verified address is now a precondition for holding a session. Better
Auth enforces that after the password check and before any session
exists, so an unverified sign-in returns 403 with no cookie. That is why
no "unverified principal" was needed: a correct password on an
unverified address carries exactly the authority of no password, and
/api/v1/principal is unchanged.

Better Auth keeps every token. Ekklesia adds no token table, no hashing,
and no expiry clock. It supplies a recipient, a subject, and two bodies,
and the mail provider supplies everything about SMTP.

Verification and reset links are rebuilt from a validated Dashboard
origin, taking only the token — never the URL Better Auth prebuilds from
a caller-supplied callbackURL — so no request can steer where a
recipient lands. Following a verification link mints no session, because
mail infrastructure dereferences links. Reset revokes that person's
other sessions and leaves managed devices alone.

Recovery answers identically for an address with an account, without
one, already verified, or undeliverable — including when SMTP is broken,
which is why the delivery adapter never throws.

The initial platform owner is the one exception: created already
verified by an operator command with no mail prerequisite, so a fresh
server can be signed in to before a relay exists. Migration 0007 extends
that to owners of installations that already exist. Public signup stays
disabled; verification is not a licence to self-register.

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

README.md

@@ -52,7 +52,8 @@ order never grants elevation — but is now **disabled by default, and cannot be
 production at all** until durable abuse controls exist (Phase 5D pass 1, below). See
 [API](docs/development/api.md) and
 [ADR 0011](docs/architecture/decisions/0011-identity-http-transport-and-public-enrollment.md).
-Email verification, password recovery, and invitation/operator enrollment still do not exist.
+Email verification and password recovery now exist (Phase 7C pass 2, below); invitation and operator
+enrollment still do not.
 Public registration remains disabled by default and prohibited in production — and a fresh
 production installation now has a supported way to get its first administrator anyway: Phase 7B
 pass 1B's `pnpm identity:create-initial-owner` (below). The Dashboard now has a minimal authenticated shell and login/logout flow,
@@ -719,12 +720,31 @@ ambiguous, and retrying it would send someone several copies of the same reset e
 single bounded attempt and deliberately not an exactly-once promise. There is **no
 `POST /api/v1/send-email`** and no route that touches the provider.
 
-Email remains **optional**: an installation with no SMTP configured is a complete deployment, since
-nothing sends mail yet. `pnpm doctor` reports the configuration and can probe connectivity **without
-sending anything**, while stating plainly that a successful connection does not establish
-deliverability. **Email verification, password reset, and invitations are Pass 2** — Better Auth's
-`sendResetPassword` and `sendVerificationEmail` hooks are still unimplemented, and this transport is
-the seam they will use. See [Outbound email](docs/development/email.md).
+Email remains **optional**: an installation with no SMTP configured is a complete deployment.
+`pnpm doctor` reports the configuration and can probe connectivity **without sending anything**,
+while stating plainly that a successful connection does not establish deliverability. See
+[Outbound email](docs/development/email.md).
+
+Phase 7C pass 2 completes the human identity lifecycle over that transport
+([ADR 0038](docs/architecture/decisions/0038-email-verification-and-password-recovery.md)). **A
+verified email address is a precondition for holding a session**: the identity system refuses an
+unverified sign-in after checking the password and before creating one, so a correct password on an
+unverified address carries exactly the authority of no password at all — which is why no
+"unverified principal" exists and `/api/v1/principal` is unchanged. Better Auth owns every token;
+Ekklesia adds no token table, no token hashing, and no expiry clock. Verification and reset links are
+rebuilt from a validated Dashboard origin rather than from anything a request supplied, so no caller
+can steer where a recipient lands, and following a verification link deliberately mints **no
+session** — mail scanners dereference links. Password reset revokes that person's other sessions and
+leaves managed devices untouched. Password recovery answers identically for an address with an
+account, without one, already verified, or undeliverable — including when SMTP is broken, which is
+why the delivery adapter never throws.
+
+**The initial platform owner is the one exception**: `pnpm identity:create-initial-owner` creates
+that account already verified and has no mail prerequisite at all, so a freshly provisioned server
+can be signed in to before any relay exists. Normal production use of verification and recovery does
+require configured outbound email. **Public signup remains disabled** — verification is not a licence
+to self-register — and invitations and user administration are still not built. See
+[Identity](docs/development/identity.md).
 
 Ekklesia publishes the display bundle at
 `GET /api/v1/module-ui/<module-id>/<version>/display`, serves a stable permission-gated page at
@@ -869,7 +889,7 @@ Object storage
 
 Outbound email
   ○ Outbound email not configured
-    No EKKLESIA_SMTP_HOST is set. This is a complete deployment: nothing in the platform sends email yet.
+    No EKKLESIA_SMTP_HOST is set. The platform runs and the bootstrap owner can sign in, but email verification and account recovery cannot deliver.
 
 Result: READY WITH WARNINGS
 ```