fix(auth): confirm an emailed verification link wherever it is opened (E9.5 S2)

The token was only ever consumed inside Welcome.tsx, which App renders ONLY when
there is no session. Opening the emailed link in a browser that already held a
Siftlode session posted nothing, the fragment was then stripped, and the user got
no signal at all -- the link simply did nothing. Incognito worked, which is why it
survived. Confirmation now happens in App, above that branch: signed out the outcome
still drives the auth card's banners, signed in it drives a top-of-app bar.

The entry URL is snapshotted once at import time (lib/entryUrl) instead of per
component, so no future URL writer can strip a token before whoever needs it has
read it -- that ordering race is what broke this in the first place. POST /auth/verify
now names the address it confirmed, which matters when the browser holds a session
for a different account; the same reasoning as password_reset_required already
covers the disclosure.

Also here, from the 2026-09-02 review tail: the dead GET /auth/verify goes (both
senders emit the fragment form, and the last query-token link expired 24h after the
0.78.7 deploy), a spent #verify=/#reset= fragment is cleared while signed in, and
the auth-card banners get role=status. The verifyOkReset copy no longer blames
admin approval, which E9.5 S1 made false.

frontend/src/lib/useVerifyEntry.ts

@@ -0,0 +1,52 @@
+import { useEffect, useRef, useState } from "react";
+import { api } from "./api";
+import { clearEntryUrl, entryHash } from "./entryUrl";
+
+/** What confirming the emailed token produced. `ok_reset` means the address is confirmed but this
+ * account's password had been revoked (SEC-10), so signing in would only meet the uniform credentials
+ * error — the user has to set a new one. */
+type VerifyOutcome = "ok" | "ok_reset" | "invalid";
+
+export type VerifyEntry = {
+  outcome: VerifyOutcome | null;
+  /** The address that was confirmed, when the server named it. */
+  email: string | null;
+  /** Dismiss the outcome — the banner is a one-time entry notice, not persistent state. */
+  dismiss: () => void;
+};
+
+/**
+ * Confirm a `#verify=` token from the entry URL, wherever the user opened it.
+ *
+ * App calls this ABOVE its signed-in/signed-out branch, which is the whole point: the token used to be
+ * consumed inside Welcome.tsx, and `App.tsx` renders <Welcome /> only when there is no session. Open
+ * the emailed link in a browser that already holds a Siftlode session and the token was never posted,
+ * the fragment was then stripped, and the user got no signal at all — the link simply did nothing.
+ * Incognito worked, which is why it survived so long.
+ *
+ * Fires exactly once. The token is single-use, so a second POST (a StrictMode remount, any re-render)
+ * would 400 and wrongly flip a successful confirmation to "invalid".
+ */
+export function useVerifyEntry(): VerifyEntry {
+  const token = entryHash.get("verify");
+  const [outcome, setOutcome] = useState<VerifyOutcome | null>(null);
+  const [email, setEmail] = useState<string | null>(null);
+  const fired = useRef(false);
+
+  useEffect(() => {
+    // Clear the address bar even with no token to consume: a `#reset=` fragment opened in a
+    // signed-in browser is equally spent, and leaving either in history re-sends it on a reload.
+    clearEntryUrl();
+    if (!token || fired.current) return;
+    fired.current = true;
+    api
+      .verifyEmail(token)
+      .then((r) => {
+        setOutcome(r.password_reset_required ? "ok_reset" : "ok");
+        setEmail(r.email ?? null);
+      })
+      .catch(() => setOutcome("invalid"));
+  }, [token]);
+
+  return { outcome, email, dismiss: () => setOutcome(null) };
+}