feat(admin): surface the sign-ups that are stuck outside, and let an admin finish letting them in (E9.5 S5)

Approve an address BEFORE the person registers and their sign-up produces no queue row at all —
`_decide` only takes a still-pending invite — so the Access-requests screen sat empty, the tab badge
read zero, and the only working move was re-typing the address into the whitelist box. Nobody would
guess that, and on 2026-09-03 nobody did.

This is roadmap UX-25, where two earlier attempts were reverted after review. Both moved AUTHORITY:
auto-activating on registration turns a standing whitelist entry into a bearer grant for whoever
registers the address first, and reopening the approved invite to `pending` lets an anonymous sign-up
REVOKE a standing approval. What was actually missing was visibility, so this changes nothing about
what an unauthenticated caller can cause — the admin could already do exactly this by re-entering the
address; they just had no way to know they had to.

The section lists every account that cannot sign in yet and says WHICH gate is shut, because the two
dead ends look the same from the admin's chair: waiting for activation, or waiting on a confirmation
mail. Naming the unconfirmed ones is not decoration — on a no-SMTP instance that is the difference
between the owner and whoever registered the address first (SEC-15), and an admin about to let
someone in should see it. A person the queue above already covers is deliberately NOT listed here;
two buttons for one person is worse than one.

Activate is gated on `is_allowed` — the same function the sign-in paths consult, in core, so the
button that appears and the badge that counts cannot disagree. Without that gate it would
manufacture an inconsistent account: password sign-in only checks `is_active` and would let them in,
while their Google sign-in would be turned away and silently reopened as a fresh access request.
Letting in someone with no approved invite stays the whitelist box's job, which says so out loud.

The badge counts activations SEPARATELY from pending invites rather than widening an existing
field's meaning, and only counts what genuinely waits on the admin: an unconfirmed account waits on
its owner, so it is listed with a re-send but does not nag. The admin-side resend says plainly what
happened, including refusing when the instance has no working SMTP — mail is fail-soft everywhere
else, and that silence is exactly what left the 0.78.5 sign-ups with nothing to fall back on.

`send_verification_link` is now one function with three callers (registration, the public resend,
this one), so the link's shape and TTL cannot drift by who triggered it.

UAT on localdev, both languages: the UX-25 shape reproduced end to end (approve the address, then
register), the badge counting it, Activate letting them in and dropping the badge, the row losing
its Activate but keeping the re-send, a fresh token issued by the re-send, and both actions in the
audit log. Test data removed.

frontend/src/components/AdminUsers.tsx

@@ -2,8 +2,26 @@ import { useState } from "react";
 import { qk } from "../lib/queryKeys";
 import { useTranslation } from "react-i18next";
 import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query";
-import { Ban, Check, RotateCcw, Shield, Trash2, UserPlus, X } from "lucide-react";
-import { api, HttpError, type AdminUserRow, type Invite, type Me } from "../lib/api";
+import {
+  Ban,
+  Check,
+  Clock,
+  MailWarning,
+  RotateCcw,
+  Send,
+  Shield,
+  Trash2,
+  UserPlus,
+  X,
+} from "lucide-react";
+import {
+  api,
+  HttpError,
+  type AdminUserRow,
+  type Invite,
+  type Me,
+  type PendingAccessRow,
+} from "../lib/api";
 import { notify } from "../lib/notifications";
 import { ADMIN_USERS_TAB_KEY } from "../lib/adminUsersTab";
 import Tooltip from "./Tooltip";
@@ -27,7 +45,14 @@ export default function AdminUsers() {
   const [tab, setTab] = usePersistedTab(ADMIN_USERS_TAB_KEY, "roles");
   const tabs = [
     { id: "roles", label: t("users.tabs.roles") },
-    { id: "access", label: t("users.tabs.access"), badge: me.pending_invites },
+    // Both kinds of "waiting on the admin": a request needing a decision, and a sign-up whose
+    // address was approved BEFORE they registered — the second never reaches the invite queue,
+    // so the badge used to read zero while somebody sat locked out (roadmap UX-25).
+    {
+      id: "access",
+      label: t("users.tabs.access"),
+      badge: me.pending_invites + me.pending_activations,
+    },
     { id: "demo", label: t("users.tabs.demo") },
   ];
   const active = tabs.some((x) => x.id === tab) ? tab : "roles";
@@ -41,7 +66,12 @@ export default function AdminUsers() {
       </PageToolbar>
       <div className="px-4 pb-4 pt-3 max-w-3xl w-full mx-auto">
         {active === "roles" && <UsersRoles me={me} />}
-        {active === "access" && <AdminInvites />}
+        {active === "access" && (
+          <>
+            <AdminInvites />
+            <PendingAccess />
+          </>
+        )}
         {active === "demo" && <AdminDemo />}
       </div>
     </>
@@ -261,6 +291,166 @@ function UsersRoles({ me }: { me: Me }) {
   );
 }
 
+// --- Sign-ups that are still outside (roadmap UX-25) --------------------------------------------
+//
+// The gap this closes: approve an address BEFORE the person registers and their sign-up produces no
+// queue row at all — `_decide` only takes a pending invite — so the Access-requests screen above was
+// empty while they sat locked out. The only working move was re-typing the address into the
+// whitelist box, which nobody would guess. This section makes the state visible and the fix one
+// click, WITHOUT changing who may cause what: the button is admin-authenticated and explicit. Two
+// earlier attempts moved authority instead (auto-activating on registration, reopening the approved
+// invite) and were reverted after review.
+function PendingAccess() {
+  const { t } = useTranslation();
+  const qc = useQueryClient();
+  const rows = useQuery({
+    queryKey: qk.adminPendingAccess(),
+    queryFn: () => api.adminPendingAccess(),
+  });
+  // Activating changes /api/me's badge count too, so refresh both or the number lies until reload.
+  const refresh = () => {
+    qc.invalidateQueries({ queryKey: qk.adminPendingAccess() });
+    qc.invalidateQueries({ queryKey: qk.me() });
+    qc.invalidateQueries({ queryKey: qk.adminUsers() });
+  };
+
+  const activate = useMutation({
+    mutationFn: (u: PendingAccessRow) => api.activateUser(u.id),
+    onSuccess: (_r, u) => {
+      refresh();
+      notify({ level: "success", message: t("users.pendingAccess.activated", { email: u.email }) });
+    },
+    onError: () => notify({ level: "error", message: t("users.pendingAccess.activateFailed") }),
+  });
+
+  const resend = useMutation({
+    mutationFn: (u: PendingAccessRow) => api.resendUserVerification(u.id),
+    onSuccess: (_r, u) => {
+      refresh();
+      notify({ level: "success", message: t("users.pendingAccess.resent", { email: u.email }) });
+    },
+    // The public resend is deliberately silent; this one is not, so say WHY it failed — an instance
+    // with no working SMTP would otherwise show a success toast for a mail that was never sent.
+    onError: (err) =>
+      notify({
+        level: "error",
+        message:
+          err instanceof HttpError && isEmailOff(err)
+            ? t("users.pendingAccess.resendEmailOff")
+            : t("users.pendingAccess.resendFailed"),
+      }),
+  });
+
+  const list = rows.data ?? [];
+  const busy = activate.isPending || resend.isPending;
+  if (rows.isSuccess && list.length === 0) return null; // nothing stuck: no empty box to explain
+
+  return (
+    <Section card title={t("users.pendingAccess.title")}>
+      <p className="text-xs text-muted leading-relaxed mb-3">{t("users.pendingAccess.body")}</p>
+      {rows.isError && !rows.data ? (
+        <StateMessage tone="error" onRetry={() => rows.refetch()}>
+          {t("common.loadError")}
+        </StateMessage>
+      ) : rows.isLoading && !rows.data ? (
+        <LoadingState />
+      ) : (
+        <div className="space-y-1.5">
+          {list.map((u) => (
+            <PendingAccessRowView
+              key={u.id}
+              row={u}
+              busy={busy}
+              onActivate={() => activate.mutate(u)}
+              onResend={() => resend.mutate(u)}
+            />
+          ))}
+        </div>
+      )}
+    </Section>
+  );
+}
+
+/** Did the resend fail because this instance has no working SMTP? */
+function isEmailOff(err: HttpError): boolean {
+  const d = err.detailData as { code?: string; reason?: string } | null | undefined;
+  return d?.code === "resend" && d.reason === "email_off";
+}
+
+// One stuck sign-up. The row names WHICH gate is shut rather than just offering buttons — the same
+// reasoning as the sign-in card's blocked panel, from the admin's side: an admin about to let someone
+// in should see that the address has not been confirmed yet, because on a no-SMTP instance that is
+// the difference between the owner and whoever registered the address first (roadmap SEC-15).
+function PendingAccessRowView({
+  row,
+  busy,
+  onActivate,
+  onResend,
+}: {
+  row: PendingAccessRow;
+  busy: boolean;
+  onActivate: () => void;
+  onResend: () => void;
+}) {
+  const { t } = useTranslation();
+  return (
+    <div className="glass-card flex items-center gap-2 p-2.5 rounded-xl">
+      <div className="min-w-0 flex-1">
+        <div className="text-sm truncate">{row.email}</div>
+        <div className="text-2xs text-muted flex items-center gap-2 mt-0.5 flex-wrap">
+          {row.created_at && (
+            <span>
+              {t("users.pendingAccess.signedUp", {
+                time: new Date(row.created_at).toLocaleString(),
+              })}
+            </span>
+          )}
+          {row.email_verified ? (
+            <span className="inline-flex items-center gap-1 text-success">
+              <Check className="w-3 h-3" />
+              {t("users.pendingAccess.emailConfirmed")}
+            </span>
+          ) : (
+            <span className="inline-flex items-center gap-1 text-warn">
+              <MailWarning className="w-3 h-3" />
+              {t("users.pendingAccess.emailUnconfirmed")}
+            </span>
+          )}
+          {!row.is_active && (
+            <span className="inline-flex items-center gap-1">
+              <Clock className="w-3 h-3" />
+              {t("users.pendingAccess.inactive")}
+            </span>
+          )}
+        </div>
+      </div>
+      {!row.email_verified && (
+        <Tooltip hint={t("users.pendingAccess.resendHint")}>
+          <button
+            onClick={onResend}
+            disabled={busy}
+            className="shrink-0 p-1.5 rounded-lg border border-border text-muted hover:text-fg disabled:opacity-50 transition"
+            aria-label={t("users.pendingAccess.resend")}
+          >
+            <Send className="w-4 h-4" />
+          </button>
+        </Tooltip>
+      )}
+      {row.can_activate && (
+        <Tooltip hint={t("users.pendingAccess.activateHint")}>
+          <button
+            onClick={onActivate}
+            disabled={busy}
+            className="shrink-0 px-2.5 py-1.5 rounded-lg border border-accent/40 text-accent text-xs font-medium hover:bg-accent/10 disabled:opacity-50 transition"
+          >
+            {t("users.pendingAccess.activate")}
+          </button>
+        </Tooltip>
+      )}
+    </div>
+  );
+}
+
 // --- Access requests (the Invite whitelist) — moved verbatim from Settings → Account -------
 
 function AdminInvites() {