fix(ui): dialogs, menus and busy buttons keep the keyboard focus where it belongs

Measured in Chrome before each change:

- A dialog opened from a menu lost its focus: the menu row ran its action
  and closed in one batch, and floating-ui's focus return (a microtask)
  moved the focus to the row BEHIND the confirm dialog's scrim 7 ms after
  it opened, where Enter activated the row. MenuItemList now closes first
  and runs the action a task later; the dialog also captures the row, not
  a dying menu item, as its restore target.
- A side panel opened as a flyout collapsed the moment a dialog opened
  from inside it, unmounting the row the dialog hands the focus back to.
  useHoverFocusWithin holds while the focus is inside an aria-modal dialog.
- ui/Button's loading state set native disabled; Chrome moved the focus of
  the pressed button to <body> and never gave it back. Loading is now
  aria-disabled with a click guard that also cancels implicit submission.
- Escape/Enter in the playlist rail's rename field dropped the focus on
  <body>. The row refocuses from its ref callback when it re-attaches (a
  post-commit focus sticks; the earlier attempt ran before the button
  existed).
- PlayerModal was the one aria-modal shell without the dialog contract:
  it is now named by its title, traps Tab, restores the focus to its
  opener and shares one counted body scroll lock with every dialog.

frontend/src/components/ui/ActionMenu.dom.test.tsx

@@ -54,13 +54,18 @@ describe("ActionMenu", () => {
     ]);
   });
 
-  it("selecting an item fires its onSelect and closes the menu", () => {
+  // Close first, act on a later task: floating-ui hands the focus back to the trigger from a microtask
+  // as the menu unmounts, and an action run in that same batch (a confirm dialog) had its focus taken
+  // back to the trigger behind the dialog's scrim — measured in Chrome, E11 S2. jsdom does not run
+  // that focus race, so the ORDER is what is pinned: the menu is gone before the action runs.
+  it("selecting an item closes the menu first, then fires its onSelect once", async () => {
     const onSelect = vi.fn();
     renderMenu([{ id: "sync", label: "Sync", onSelect }]);
     fireEvent.click(screen.getByRole("button", { name: "Catalog actions" }));
     fireEvent.click(screen.getByText("Sync"));
-    expect(onSelect).toHaveBeenCalledTimes(1);
     expect(screen.queryByRole("menuitem", { hidden: true })).toBeNull();
+    expect(onSelect).not.toHaveBeenCalled();
+    await vi.waitFor(() => expect(onSelect).toHaveBeenCalledTimes(1));
   });
 
   it("a disabled item is inert — rendered disabled and never fires onSelect", () => {