feat(ui): the four small gaps — player delete, repeat-move, a real channel link, YT search sorting

Items 2, 4, 5 and 7 of the bug hunt, one round. They are independent, but they are all the same
kind of thing: an action that exists somewhere else in the app and is missing where you actually
want it.

**5 — the channel name in the YT player is a link again.** It was a `<button>`, so middle-click and
Ctrl/Cmd-click did nothing on a thing that looks exactly like a link (the YouTube icon beside it IS
an anchor and opens a tab). It is now a real `<a>` whose href is the same `?chan=<id>` URL
`openChannel` pushes, with a plain left click still taking the in-app path — that path does more
than navigate, since the player must close and reclaim its own Back-to-close history entry first.
The "is this click ours or the browser's" test is now ONE predicate (`isPlainLeftClick`), which
VideoCard's card link also uses, so a second such link cannot forget the middle-click arm.

**2 — "Remove" from inside the player.** The parent owns the removal (the SAME `removeItem` the row
menu and the inline ✕ use: one confirm, one optimistic update, one undo-stack rebase), and the
player owns what happens next, because it is the only side that knows which item is playing — its
launch queue is frozen at mount. It drops the item, plays what followed, and closes when the list
runs out. That forced a real fix in Playlists: the player's mount was derived from `shown` every
render, so anything that dropped the launch row yanked the player off the screen mid-playback. That
was a latent edge (change the view and it happens) and the normal case for this feature. The parent
now snapshots what it launched with, and only onClose takes the player down.

**4 — "Move to <the last list you moved to>".** The submenu is two levels deep and moving a run of
videos into the same list is the shape this gets used in. The remembered id is a per-account pref;
the row is derived from `moveTargets`, which already excludes the list you are looking at, so it
cannot offer a move to where the video already is. Remembered only on a SUCCESSFUL move — a
shortcut to a move that failed is a shortcut to failing again. Absent, not disabled, when there is
nothing to repeat: there is nothing to explain.

**7 — the live-YouTube results can be sorted.** Client-side, over the page already loaded. Not a
new `order=` param, and this is the decision worth recording: the owner's case is "even one page of
results", i.e. reorder what is on screen; a re-query would REPLACE the results, which is not what
"sort these" means; and the zero-quota scrape source has no order parameter at all, so a
server-side control would silently do nothing (or quietly cost 100 quota units) depending on which
source served the page. Only keys a search hit carries are offered — `subscribers`/`priority`
describe a subscription, which a search hit is not, and `shuffle` on a ranked list is noise. Its
own pref, so sorting a search page never re-sorts the library behind it.

Verified in the browser on localdev against the real account: the channel name renders as
`<a href="…&chan=…">` and a ctrl-click / middle-click is left to the browser while a plain click
still opens the channel in-app; removing from the player stepped 1/3 → 1/2 onto the next video and
closed on the last one; the row menu grew "Move to “…”" only after a move and only on a list that
is not the target; and the results sort reordered by views 41.7M → 29.8M → 24.2M → 15.8M. (The
pane's own ctrl-click arrives without the modifier — a harness limit, so the modifier cases were
driven as real MouseEvents.) Scratch playlists and the touched prefs were cleaned up afterwards.

22 vitest, mutation-checked against 14 mutations (no href at all · href without the rest of the
query · every click hijacked in-app · the middle-click arm dropped from the predicate · plain click
no longer in-app · always jumping to the top of the list · the removed item left in the queue · no
clamp when the last item goes · an empty queue not reported as "nothing left" · sort-then-reverse
flipping ties · unknown values first · titles compared numerically · shuffle offered on search
results · direction ignored) — each red on exactly the test that names it. Item 4 has no test of
its own: its rule is enforced by construction, not by a check.

frontend/src/lib/feedSort.ts

@@ -1,6 +1,7 @@
 // The feed's sort vocabulary. `FeedFilters.sort` is a single wire string ("newest", "views_asc",
 // …); the UI thinks in a key + direction. Kept here rather than inside Feed so the active-filter
 // chips can label a sort without re-deriving the mapping.
+import type { Video } from "./api";
 
 export type SortKey =
   | "date"
@@ -56,3 +57,44 @@ export function buildSort(key: SortKey, dir: "asc" | "desc"): string {
   if (key === "shuffle" || key === "relevance") return key;
   return SORT_MAP[key][dir];
 }
+
+// --- Live YouTube search results ----------------------------------------------------------------
+//
+// The results view had NO sort control at all — the order was the provider's and that was that. It is
+// sorted HERE, on the page already loaded, rather than by re-asking YouTube with an `order=` param,
+// for three reasons: the owner's case is "even one page of results", i.e. reorder what is on screen;
+// a re-query would REPLACE the results, which is not what "sort these" means; and the zero-quota
+// scrape source has no order parameter at all, so a server-side control would silently do nothing (or
+// quietly cost 100 quota units) depending on which source happened to serve the page.
+//
+// Only the keys a search result actually carries are offered. `subscribers` and `priority` are
+// properties of a SUBSCRIPTION, which a live search result is not, and `shuffle` on a ranked result
+// list is noise — an option that cannot mean anything here is worse than no option.
+export const YT_SORT_KEYS: SortKey[] = ["relevance", "date", "popular", "duration", "title"];
+
+const YT_SORT_VALUE: Partial<Record<SortKey, (v: Video) => number | string | null | undefined>> = {
+  date: (v) => (v.published_at ? Date.parse(v.published_at) : null),
+  popular: (v) => v.view_count,
+  duration: (v) => v.duration_seconds,
+  title: (v) => v.title,
+};
+
+/** Order a loaded page of live-search results. `relevance` is the provider's own ranking, i.e. the
+ *  order they arrived in — so it is the identity, not a sort.
+ *
+ *  Results missing the value sink to the END in both directions (a video whose duration YouTube did
+ *  not report is not "the shortest"), and ties keep the provider's ranking, in both directions —
+ *  hence a signed comparator rather than sorting and reversing, which would flip the ties too. */
+export function sortYtResults(items: Video[], key: SortKey, dir: "asc" | "desc"): Video[] {
+  const value = YT_SORT_VALUE[key];
+  if (!value) return items; // relevance, and anything a stale pref names that we no longer offer
+  const sign = dir === "asc" ? 1 : -1;
+  const have = items.filter((v) => value(v) != null);
+  const missing = items.filter((v) => value(v) == null);
+  have.sort((a, b) => {
+    const x = value(a)!;
+    const y = value(b)!;
+    return sign * (typeof x === "string" ? x.localeCompare(String(y)) : x - Number(y));
+  });
+  return [...have, ...missing];
+}