fix(keys): epic-end review round 1 — Back, menus and dialogs keep the focus where it belongs

Deep-review of E11 (19 raised, 14 confirmed; 2 refuted, 3 latent test-hardening notes dropped).

- Back from a sub-view (a Plex show page, a Messages thread) restores the item it was opened from
  even when focus was still inside the view: the first attempt now waits one task, past the
  sub-view's own popstate listener (measured in Chrome: it left focus on <body>).
- The restore listener is installed at load, so the first Back after a reload finds it; a push
  cancels a restore still waiting for the last landing's lists.
- Navigating over an overlay asks it again, a render apart, while its entry stays: the Plex
  player peels one panel per Back step, so Shift+W over info + stats closed one panel and dropped
  the navigation.
- j/k: a native <button> item keeps its own Tab stop; landing twice on the same item no longer
  leaks its tabindex; after the focused item is removed (a hidden card) the next j goes on from
  its slot when that slot is on screen.
- An abandoned `g` no longer swallows a modifier chord (g, then Mod+K opened the browser search).
- A hover card above a dialog no longer switches its Tab trap off (player, Modal, wizard,
  Lightbox): new layerStack `anyBlockingLayerAbove`.
- "Manage views…" closes its menu before opening the dialog, through a shared `closeThenAct`
  that ActionMenu now uses too.
- Copy: the EN welcome says "Feed"; the EN unreachable reason no longer claims a change;
  stale comments about PlayerModal's scroll lock and dialog contract.

frontend/src/components/SavedViewsPopover.dom.test.tsx

@@ -0,0 +1,51 @@
+// @vitest-environment jsdom
+//
+// "Manage views…" opens a dialog from a menu row, so it must close the menu FIRST and open the dialog
+// on a fresh task (`closeThenAct`): the menu's focus return, queued as it unmounts, otherwise takes the
+// dialog's focus back to the trigger behind its scrim — measured in Chrome on ActionMenu (E11 S2), and
+// this row was the sibling that fix missed (deep-review E11 round 1). jsdom does not run that focus
+// race, so the ORDER is what is pinned: the menu is gone before the dialog is asked to open.
+import { beforeAll, describe, expect, it, vi } from "vitest";
+import { fireEvent, render, screen } from "@testing-library/react";
+import { FloatingTree } from "@floating-ui/react";
+
+const openModal = vi.fn();
+vi.mock("react-i18next", async (importOriginal) => {
+  const actual = await importOriginal<typeof import("react-i18next")>();
+  return { ...actual, useTranslation: () => ({ t: (key: string) => key }) };
+});
+vi.mock("./SavedViewsProvider", () => ({
+  useSavedViews: () => ({ views: [], activeViewId: null, apply: vi.fn(), openModal }),
+}));
+
+import SavedViewsPopover from "./SavedViewsPopover";
+
+beforeAll(() => {
+  class Stub {
+    observe() {}
+    unobserve() {}
+    disconnect() {}
+    takeRecords() {
+      return [];
+    }
+  }
+  globalThis.ResizeObserver ??= Stub as unknown as typeof ResizeObserver;
+  globalThis.IntersectionObserver ??= Stub as unknown as typeof IntersectionObserver;
+});
+
+describe("SavedViewsPopover · Manage views…", () => {
+  it("closes the menu first, then opens the dialog once", async () => {
+    render(
+      <FloatingTree>
+        <SavedViewsPopover trigger="views" ariaLabel="Saved views" />
+      </FloatingTree>,
+    );
+    fireEvent.click(screen.getByRole("button", { name: "Saved views" }));
+    // floating-ui never positions in jsdom, so the surface stays visibility:hidden and the row has no
+    // accessible name to query by: find it by its text.
+    fireEvent.click(screen.getByText("views.manage"));
+    expect(screen.queryByRole("menuitem", { hidden: true })).toBeNull();
+    expect(openModal).not.toHaveBeenCalled();
+    await vi.waitFor(() => expect(openModal).toHaveBeenCalledTimes(1));
+  });
+});