fix(keys): epic-end review round 2 — focus comes back to the card, the right rail and the reason

Whole-epic deep-review of E11 (18 raised, 12 kept; B and G refuted, four latent test-hardening notes dropped),
plus the admin refusal copy gap round 1 surfaced.

- A context menu opened from a card the keyboard is on gives the focus back to the card. floating-ui returns
  focus through the opener's first tabbable descendant even when handed a ref, so for a non-tabbable opener the
  surface restores it itself (measured in Chrome: j, Shift+F10, Escape left it on the thumbnail link).
- Back finds a named list (a rail) by its name: a rail that appeared above it after the cache expired sent the
  focus into the wrong rail. An unnamed list is matched only when the page has the same number of lists.
- The slot kept for a removed item is forgotten once focus moves on to page content (search, a chip), so j after
  new results starts at the first visible item; a menu or dialog opened from the item keeps it.
- The list keys reach the cheat sheet only while a list has an item.
- A j-focused card root is a named group while it holds the focus.
- The channel page's Block and Hide toggles keep the focus while their request runs.
- A split export that fails part-way says how many clips were added and deselects them, so a retry adds only
  the rest.
- Config save, the one-click share link and "log out other sessions" report failures with their reason.
- VirtualGrid uses the one scroll-parent walk listNav measures against.
- Admin refusals (activate, resend, invite, set-password link) say why in HU and EN instead of "try again";
  the email-off special cases collapse into that one reason. The contract reads the codes from localizeDetail.
  HU copy points to Konfiguráció → E-mail / SMTP; HU "unreachable" matches the EN change of round 1.

frontend/src/components/AdminUsers.tsx

@@ -24,7 +24,7 @@ import {
   type PendingAccessRow,
 } from "../lib/api";
 import { notify } from "../lib/notifications";
-import { invalidateUserAccess, isEmailOff } from "../lib/adminUsers";
+import { invalidateUserAccess } from "../lib/adminUsers";
 import { ADMIN_USERS_TAB_KEY } from "../lib/adminUsersTab";
 import { Button } from "./ui/Button";
 import Tooltip from "./ui/Tooltip";
@@ -319,12 +319,6 @@ function UsersRoles({ me }: { me: Me }) {
   );
 }
 
-/** Did the invitation fail because this instance has no working SMTP? */
-function inviteEmailOff(err: HttpError): boolean {
-  const d = err.detailData as { code?: string; reason?: string } | null | undefined;
-  return d?.code === "invite_send" && d.reason === "email_off";
-}
-
 // --- 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
@@ -360,12 +354,9 @@ function PendingAccess() {
       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) =>
-      isEmailOff(err)
-        ? notifyKnownFailure(err, t("users.pendingAccess.resendEmailOff"))
-        : notifyActionError(err, t("users.pendingAccess.resendFailed")),
+    // The public resend is deliberately silent; this one is not, and the server's reason says WHY
+    // (no working SMTP, a refused send) — a success toast for a mail never sent would be the lie.
+    onError: (err) => notifyActionError(err, t("users.pendingAccess.resendFailed")),
   });
 
   const list = rows.data ?? [];
@@ -591,10 +582,7 @@ function AdminInvites() {
       refresh();
       notify({ level: "success", message: t("settings.invites.invited", { email: v.inv.email }) });
     },
-    onError: (err) =>
-      err instanceof HttpError && inviteEmailOff(err)
-        ? notifyKnownFailure(err, t("settings.invites.inviteEmailOff"))
-        : notifyActionError(err, t("settings.invites.inviteFailed")),
+    onError: (err) => notifyActionError(err, t("settings.invites.inviteFailed")),
   });
   // The one recipient the app has no language signal about: the admin typed this address in, so
   // nobody ever told us how to write to its owner. The dialog is where that gets decided — and it