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]>

surfaces/shell/src/browser/main.tsx

@@ -1,4 +1,5 @@
 import { createRoot } from "react-dom/client";
+import { type HostAuthLanding, readAuthLanding } from "../auth-protocol.js";
 import type { EkklesiaHostConfig } from "../host-protocol.js";
 import { HostApp } from "./HostApp.js";
 
@@ -23,9 +24,42 @@ const config: EkklesiaHostConfig = {
   apiBaseUrl: __EKKLESIA_API_BASE_URL__ || window.location.origin,
 };
 
+/**
+ * Captures what an emailed verification or reset link asked for, then removes it from the address
+ * bar.
+ *
+ * A password-reset token is a bearer credential for one account. Leaving it in `location.search`
+ * would put it in the browser's history, in the tab title's shareable URL, and in the `Referer` of
+ * anything the page subsequently loaded. `history.replaceState` rewrites the entry in place rather
+ * than pushing a new one, so the Back button cannot return to the URL that held it. It is
+ * deliberately *not* stored anywhere afterwards — it lives only in React state for the lifetime of
+ * the reset form, and never in `localStorage` or `sessionStorage`.
+ *
+ * The parse is a pure function that recognizes only Ekklesia's own two landings, so nothing in the
+ * query string can name a destination.
+ */
+function captureAuthLanding(): HostAuthLanding | undefined {
+  const landing = readAuthLanding(window.location.search);
+  if (!landing) {
+    return undefined;
+  }
+  try {
+    window.history.replaceState(null, "", window.location.pathname);
+  } catch {
+    // A browser that refuses the rewrite (an exotic sandbox, a file: URL) must still be able to
+    // finish the flow: the token is already captured, and failing here would strand the person on a
+    // page that cannot do anything.
+  }
+  return landing;
+}
+
+const authLanding = captureAuthLanding();
+
 const container = document.getElementById("ekklesia-host");
 if (!container) {
   throw new Error("The Ekklesia shell requires a #ekklesia-host element.");
 }
 
-createRoot(container).render(<HostApp config={config} />);
+createRoot(container).render(
+  authLanding ? <HostApp authLanding={authLanding} config={config} /> : <HostApp config={config} />,
+);