feat(playlists): hybrid table over the drag list, and guard its destructive paths

The column sort and the filters are a VIEW; the playlist's stored order only
changes when the user presses "Save this order", which still goes through the
undoable path. Picking a sort used to write straight to the server, so merely
looking at the list by title rewrote the playlist and marked a YouTube-linked
mirror dirty.

The table:
- playlistColumns.tsx holds the column defs; the body renders them as table rows
  and fills the grip cell itself, since the handle needs the row's sortable
  listeners that a render closure can't reach.
- The # column shows the STORED position, so a view-sort never renumbers the
  playlist under the reader.
- Saving is withheld while a filter is active (it would drop the hidden items),
  and drag is disabled under any view, with the reason spelled out rather than
  silently doing nothing.
- applyView/sameOrder live in lib/playlistView.ts with tests: the sort and the
  channel grouping compose, and getting that wrong produces a plausible order
  that the save button would then persist.
- dnd-kit KeyboardSensor: the grip was focusable and called itself "reorder",
  but only a pointer could move it.

The guards:
- Delete is ONE dialog with every outcome. It was two chained confirms where the
  second one's Cancel/Escape/backdrop meant "delete here only" — dismissing the
  dialog deleted the playlist. ConfirmProvider gained useChoice() for it.
- ConfirmProvider focuses Cancel when an offered action is destructive; the
  confirm button took autoFocus unconditionally, so a stray Enter on an open
  dialog ran "Delete user" or "Clear audit log".
- Removing an item asks first, and rebases the undo history instead of throwing
  it away: useUndoable.rebase maps every snapshot, so the reorder history stays
  valid for the remaining items.
- A failed detail query showed "Loading…" forever; it now says so and offers a
  retry. Rename and reorder failures are surfaced instead of swallowed (reorder
  was a bare .then(), which also produced an unhandled rejection).
- Local reorder/remove no longer require YouTube write scope.
- playlistName() replaces the watch-later localizer copied into three files.

frontend/src/lib/playlistName.ts

@@ -0,0 +1,7 @@
+import type { TFunction } from "i18next";
+
+/** Watch later is a built-in playlist whose stored `name` is not translatable — show the localized
+ * label instead. Was hand-inlined in Playlists, PlaylistsRail and AddToPlaylist; one copy now. */
+export function playlistName(p: { kind: string; name: string }, t: TFunction): string {
+  return p.kind === "watch_later" ? t("playlists.watchLater") : p.name;
+}

frontend/src/lib/playlistView.test.ts

@@ -0,0 +1,106 @@
+import { describe, expect, it } from "vitest";
+import { applyView, sameOrder } from "./playlistView";
+import type { Column } from "../components/tableHeader";
+import type { Video } from "./api";
+
+// The playlist's view derivation (E4 S4). What makes it worth a test: the column sort and the
+// channel grouping compose — groups are ordered by channel name in the SORT's direction, and the
+// sort then applies within each group. Getting that backwards silently produces a plausible-looking
+// order, and the whole "save this order" feature writes whatever this function returned.
+
+const v = (id: string, title: string, channel: string, secs: number | null = 60): Video =>
+  ({ id, title, channel_title: channel, duration_seconds: secs }) as Video;
+
+const columns = [
+  { key: "title", header: "Title", render: () => null, sortable: true, sortValue: (x: Video) => x.title ?? "" },
+  { key: "channel", header: "Channel", render: () => null, sortable: true, sortValue: (x: Video) => x.channel_title ?? "" },
+  {
+    key: "duration",
+    header: "Length",
+    render: () => null,
+    sortable: true,
+    sortValue: (x: Video) => x.duration_seconds ?? Number.MAX_SAFE_INTEGER,
+  },
+] as Column<Video>[];
+
+const titles = (rows: Video[]) => rows.map((r) => r.title);
+
+describe("applyView", () => {
+  const rows = [
+    v("1", "delta", "Beta"),
+    v("2", "alpha", "Alpha"),
+    v("3", "charlie", "Beta"),
+    v("4", "bravo", "Alpha"),
+  ];
+
+  it("returns the stored order untouched with no sort and no grouping", () => {
+    expect(applyView(rows, columns, null, false)).toBe(rows);
+  });
+
+  it("sorts by the named column", () => {
+    expect(titles(applyView(rows, columns, { key: "title", dir: "asc" }, false))).toEqual([
+      "alpha",
+      "bravo",
+      "charlie",
+      "delta",
+    ]);
+    expect(titles(applyView(rows, columns, { key: "title", dir: "desc" }, false))).toEqual([
+      "delta",
+      "charlie",
+      "bravo",
+      "alpha",
+    ]);
+  });
+
+  it("groups by channel, ordering the groups by name and sorting within each", () => {
+    expect(titles(applyView(rows, columns, { key: "title", dir: "asc" }, true))).toEqual([
+      "alpha", // Alpha
+      "bravo", // Alpha
+      "charlie", // Beta
+      "delta", // Beta
+    ]);
+  });
+
+  it("reverses the GROUP order too when the sort is descending", () => {
+    expect(titles(applyView(rows, columns, { key: "title", dir: "desc" }, true))).toEqual([
+      "delta", // Beta first, because the direction flips the group order as well
+      "charlie",
+      "bravo", // then Alpha
+      "alpha",
+    ]);
+  });
+
+  it("groups without a sort by keeping each group's stored order", () => {
+    expect(titles(applyView(rows, columns, null, true))).toEqual([
+      "alpha",
+      "bravo",
+      "delta",
+      "charlie",
+    ]);
+  });
+
+  it("parks unknown durations at the end of an ascending sort, not at zero", () => {
+    const mixed = [v("1", "long", "A", 900), v("2", "live", "A", null), v("3", "short", "A", 30)];
+    expect(titles(applyView(mixed, columns, { key: "duration", dir: "asc" }, false))).toEqual([
+      "short",
+      "long",
+      "live",
+    ]);
+  });
+});
+
+describe("sameOrder", () => {
+  const a = [v("1", "x", "A"), v("2", "y", "A")];
+
+  it("is true for the same ids in the same positions", () => {
+    expect(sameOrder(a, [v("1", "different title", "B"), v("2", "y", "A")])).toBe(true);
+  });
+
+  it("is false when the order differs", () => {
+    expect(sameOrder(a, [a[1]!, a[0]!])).toBe(false);
+  });
+
+  it("is false when the length differs — a filtered view is never 'the same order'", () => {
+    expect(sameOrder(a, [a[0]!])).toBe(false);
+  });
+});

frontend/src/lib/playlistView.ts

@@ -0,0 +1,42 @@
+import { sortRows, type SortState } from "./columnSort";
+
+// The playlist detail's VIEW derivation: what the reader sees, as opposed to the playlist's stored
+// order. Kept structural (no `Column`, no component imports) like `columnSort.ts`, so it stays pure
+// and testable — the "save this order" button writes whatever `applyView` returned, which is reason
+// enough for this to be covered rather than eyeballed.
+
+interface Grouped {
+  channel_title?: string | null;
+}
+interface Sortable<T> {
+  key: string;
+  sortValue?: (row: T) => string | number;
+}
+
+/** Filters are applied by the caller; this is sort, then optional channel grouping. Groups are
+ * ordered by channel name in the sort's direction, and the sort applies WITHIN each group (with no
+ * sort, each group keeps its stored order). */
+export function applyView<T extends Grouped>(
+  rows: T[],
+  columns: Sortable<T>[],
+  sort: SortState,
+  group: boolean
+): T[] {
+  const sorted = sortRows(rows, columns, sort);
+  if (!group) return sorted;
+  const groups = new Map<string, T[]>();
+  for (const v of sorted) {
+    const k = v.channel_title ?? "";
+    const g = groups.get(k);
+    if (g) g.push(v);
+    else groups.set(k, [v]);
+  }
+  const sign = sort?.dir === "desc" ? -1 : 1;
+  const keys = [...groups.keys()].sort((a, b) => sign * a.localeCompare(b));
+  return keys.flatMap((k) => groups.get(k)!);
+}
+
+/** Same items in the same positions. Identity is the id, so a refetch that changed only a title
+ * doesn't read as a reorder — and a shorter list (a filtered view) is never "the same order". */
+export const sameOrder = (a: { id: string }[], b: { id: string }[]) =>
+  a.length === b.length && a.every((v, i) => v.id === b[i]!.id);

frontend/src/lib/useUndoable.ts

@@ -15,6 +15,7 @@ export interface Undoable<T> {
   value: T;
   set: (next: T) => void;
   reset: (value: T) => void;
+  rebase: (map: (value: T) => T) => void;
   undo: () => void;
   redo: () => void;
   canUndo: boolean;
@@ -77,11 +78,27 @@ export function useUndoable<T>(
     force();
   }, []);
 
+  // Apply the same transformation to EVERY snapshot — past, present and future — and keep the
+  // history. For changes that are outside the undoable dimension but invalidate the snapshots:
+  // removing a playlist item is not itself undoable, yet dropping it from each stored order keeps
+  // the user's reorder history valid and usable instead of throwing it away (which is what a
+  // `reset` does). No `onApply`: the caller is already persisting the change by its own route.
+  const rebase = useCallback((map: (value: T) => T) => {
+    const s = ref.current;
+    ref.current = {
+      past: s.past.map(map),
+      present: map(s.present),
+      future: s.future.map(map),
+    };
+    force();
+  }, []);
+
   const h = ref.current;
   return {
     value: h.present,
     set,
     reset,
+    rebase,
     undo,
     redo,
     canUndo: h.past.length > 0,