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/ui/ContextMenu.dom.test.tsx

@@ -130,6 +130,42 @@ describe("useContextMenu / ContextMenu", () => {
     expect(menuitems()).toEqual([]);
   });
 
+  // A card the keyboard is on is focused as a whole, through a tabindex=-1 root (lib/listNav), and
+  // holds tabbable controls. floating-ui handed the focus back to the first of them instead of the
+  // card — measured in Chrome (deep-review E11 round 2): j, Shift+F10, Escape left it on the thumbnail.
+  // Closed here by picking the row (the other way out; jsdom delivers no Escape to a keyboard-opened
+  // menu — Escape is measured in the browser).
+  it("gives the focus back to a card focused as a whole, not to a control inside it", async () => {
+    function Card() {
+      const menu = useContextMenu<string>();
+      return (
+        <>
+          <div tabIndex={-1} data-testid="card" {...menu.triggerProps("card")}>
+            <a href="#thumb">thumbnail</a>
+          </div>
+          <ContextMenu
+            menu={menu}
+            ariaLabel="Card actions"
+            items={menu.target ? [{ id: "a", label: "Pin", onSelect: vi.fn() }] : []}
+          />
+        </>
+      );
+    }
+    render(
+      <FloatingTree>
+        <Card />
+      </FloatingTree>,
+    );
+    const card = screen.getByTestId("card");
+    act(() => card.focus());
+    fireEvent.keyDown(card, { key: "F10", shiftKey: true });
+    expect(menuitems()).toEqual(["Pin"]);
+    await vi.waitFor(() => expect(card.contains(document.activeElement)).toBe(false));
+    fireEvent.click(item("Pin"));
+    expect(menuitems()).toEqual([]);
+    await vi.waitFor(() => expect(document.activeElement).toBe(card));
+  });
+
   describe("long press (touch)", () => {
     const press = (el: HTMLElement, x = 10, y = 10) =>
       fireEvent.pointerDown(el, { pointerType: "touch", clientX: x, clientY: y });