fix(ui): a dialog opens focused where it said it would, and the wizard is a dialog

Deep-review round 5, over round 4's own fixes.

- Round 4 gave `ui/Modal` a persistent portal host so a fullscreen transition would stop tearing
  the dialog down. The host was attached in a `useLayoutEffect` — one commit phase AFTER React
  runs `autoFocus` in `commitMount`, and `focus()` on a disconnected node is a no-op. Every
  autoFocus in every dialog was dead: Mod+K opened the command palette with the focus on the ✕,
  so typing searched nothing and Enter closed it; the same for the download rename field and
  every non-danger confirm. The host is attached in a `useInsertionEffect` now, a whole phase
  earlier, and the whole re-parent — including the focus save/restore across the move, which
  `appendChild` needs because it is remove-then-insert — lives in one `useFullscreenPortalHost`.
  `ui/AnchoredPopover` had a second copy of that re-parent WITHOUT the focus restore, and a
  comment claiming focus survived it; both now come from the hook.

- `ui/Toaster` classified a toast raised in the SAME commit as a host takeover among the ones it
  inherits, because it read the store live at the takeover render. A dialog that notifies and
  closes in one handler (UploadDialog) therefore put its toast up with no role, into a region
  still `aria-live="off"` — announced by neither path. "Inherited" is now what the outgoing host
  last had on screen, and a toast that is NOT inherited is announced even inside the unarmed
  window.

- The onboarding wizard renders its own shell, and Escape ordering was all of the dialog contract
  it had: no role, no label, no initial focus, no trap, no restore. A keyboard user tabbed out of
  the first-login wizard into the app behind the scrim. The focus half of the contract is now one
  shared `ui/dialogFocus` that both `ui/Modal` and the wizard use.

Every fix has a regression test, each mutation-checked (6 mutations, all red on the assertion
they are named after).

frontend/src/components/ui/dialogFocus.ts

@@ -0,0 +1,72 @@
+import { useEffect, useState, type RefObject } from "react";
+
+// The focus half of the dialog contract, in ONE place. `ui/Modal` owns it for every dialog that goes
+// through the shell; the onboarding wizard renders its own shell (a bare `ui/Overlay`, because it is
+// not a titled dialog with a header row) and used to have NONE of this — no trap, no initial focus,
+// no restore — so a keyboard user tabbed straight out of the first-login wizard into the app behind
+// the scrim, where the focus ring is invisible (deep-review round 5). A second hand-written copy is
+// how two shells drift apart; this is the shared one.
+
+// Tabbable elements inside the dialog, in DOM order. `:not([tabindex="-1"])` drops programmatically
+// focusable-only nodes; the visibility filter (offsetParent) drops display:none ones (e.g. a
+// collapsed disclosure) so the trap never lands focus on something the user can't see.
+const FOCUSABLE =
+  'a[href], button:not([disabled]), textarea:not([disabled]), input:not([disabled]), select:not([disabled]), [tabindex]:not([tabindex="-1"])';
+
+const focusablesIn = (root: HTMLElement): HTMLElement[] =>
+  [...root.querySelectorAll<HTMLElement>(FOCUSABLE)].filter((el) => el.offsetParent !== null);
+
+/** Keep Tab / Shift+Tab cycling inside `scope` instead of reaching the inert page behind the
+ *  backdrop. Call from a keydown handler that has already decided this dialog is the topmost layer —
+ *  a nested dialog must defer to its child. `container` is the scope's own tabIndex=-1 panel, if it
+ *  has one: focus can land there by clicking dialog dead space, and `Node.contains(self)` is true, so
+ *  without naming it a Shift+Tab from the panel would leak to the background. */
+export function trapTab(
+  e: KeyboardEvent,
+  scope: HTMLElement,
+  container?: HTMLElement | null,
+): void {
+  const items = focusablesIn(scope);
+  const first = items[0];
+  const last = items[items.length - 1];
+  if (!first || !last) {
+    e.preventDefault();
+    return;
+  }
+  const active = document.activeElement;
+  if (!scope.contains(active) || (container != null && active === container)) {
+    e.preventDefault();
+    (e.shiftKey ? last : first).focus();
+  } else if (e.shiftKey && active === first) {
+    e.preventDefault();
+    last.focus();
+  } else if (!e.shiftKey && active === last) {
+    e.preventDefault();
+    first.focus();
+  }
+}
+
+/** The rest of the contract: lock the page behind, open focused, hand the focus back on close.
+ *  `scopeRef` is the panel the focus should land in. */
+export function useDialogChrome(scopeRef: RefObject<HTMLElement | null>): void {
+  // Capture the trigger to restore focus to, during THIS render — i.e. before commit runs the
+  // dialog's autoFocus (or our own initial focus) and moves activeElement into the dialog. Reading it
+  // later (in the effect) would capture a now-inside element that unmounts on close, stranding focus
+  // on <body>. useState initializer runs exactly once, on first render.
+  const [restoreTo] = useState(() => document.activeElement as HTMLElement | null);
+  useEffect(() => {
+    const prev = document.body.style.overflow;
+    document.body.style.overflow = "hidden";
+    // Initial focus: unless an autoFocus child already placed it inside (e.g. a rename input), move
+    // focus to the first control so the dialog opens focused, not stranded on the background.
+    const scope = scopeRef.current;
+    if (scope && !scope.contains(document.activeElement)) {
+      (focusablesIn(scope)[0] ?? scope).focus();
+    }
+    return () => {
+      document.body.style.overflow = prev;
+      // Restore focus to the trigger, if it's still in the document and focusable.
+      if (restoreTo && restoreTo.isConnected) restoreTo.focus();
+    };
+  }, [restoreTo, scopeRef]);
+}