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/api/auth.ts

@@ -41,7 +41,11 @@ export const authApi = {
   // in would fail with the uniform credentials error. The card sends the user to the reset flow instead
   // of leaving them to guess. Rare since E9.5 S1: only accounts stripped before that change, and the
   // Google-adoption path, still reach it.
-  verifyEmail: (token: string): Promise<{ ok: boolean; password_reset_required?: boolean }> =>
+  // `email` is the address that was just confirmed — echoed back so the banner can name it, which
+  // matters when the browser holds a session for a DIFFERENT account.
+  verifyEmail: (
+    token: string,
+  ): Promise<{ ok: boolean; password_reset_required?: boolean; email?: string }> =>
     req("/auth/verify", { method: "POST", body: JSON.stringify({ token }) }, { quiet: true }),
   // Re-issue a verification link (the first one expired, or was lost). Uniform response — never
   // reveals whether the email has a pending account.