Import a shared playlist link and build it in Navidrome

Paste a Spotify, Apple Music or Deezer playlist URL; muse resolves it, matches
every track through the same Deezer path a pasted line takes, and writes an
.m3u the library scanner picks up.

Written per import rather than at the end, so the playlist appears in Navidrome
with the first track that lands and grows as the rest arrive -- twenty minutes
of nothing, then everything, is the worse shape. A track rejected in review
drops out on the next rewrite, and one that never resolves is reported instead
of silently vanishing.

Resolve is split from queue on purpose: a shared link is opaque, you cannot
tell twelve tracks from four hundred by looking at it, and four hundred is a
quota decision.

Two of the three sources are scrapes and the code says so plainly. Deezer has a
real API. Spotify and Apple Music have no free way to read a public playlist --
Apple's MusicKit needs a paid developer account -- so those read the public page
and parse the JSON it already embeds for its own player. No key, no OAuth, no
account, and no guarantee: they break whenever either company reshuffles their
frontend. So the resolvers fail loudly and name themselves, because an empty
playlist and a changed page must not produce the same message.

The .m3u uses MUSE_PLAYLIST_PREFIX (/music), not muse's own library path. Both
containers mount the same directory at different points and a playlist written
with muse's view resolves to nothing on Navidrome's side.

Also reorders the hooks in search-bar so the URL-seeding effect is declared
after the state it sets, rather than closing over a binding declared below it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

web/components/search-bar.tsx

@@ -23,24 +23,26 @@ export function SearchBar({
   onArtist: (id: number) => void;
 }) {
   const [q, setQ] = React.useState(initial ?? "");
-  // Follows the URL on Back/Forward, but never fights what is being typed:
-  // only a genuinely different incoming query replaces the field.
-  const seeded = React.useRef(initial);
-  React.useEffect(() => {
-    if (initial !== undefined && initial !== seeded.current) {
-      seeded.current = initial;
-      typed.current = false;
-      setQ(initial);
-      setOpen(false);
-    }
-  }, [initial]);
   const [items, setItems] = React.useState<Item[]>([]);
   const [open, setOpen] = React.useState(false);
+  const [sel, setSel] = React.useState(-1);
+  const inputRef = React.useRef<HTMLInputElement>(null);
   // A value seeded from the URL must not pop the suggestion list open over the
   // results that link was for. Only typing counts as asking for suggestions.
   const typed = React.useRef(false);
-  const [sel, setSel] = React.useState(-1);
-  const inputRef = React.useRef<HTMLInputElement>(null);
+  const seeded = React.useRef(initial);
+
+  // Follows the URL on Back/Forward, but never fights what is being typed:
+  // only a genuinely different incoming query replaces the field. Declared
+  // after the state it sets, or the effect closes over a binding that is not
+  // initialised yet.
+  React.useEffect(() => {
+    if (initial === undefined || initial === seeded.current) return;
+    seeded.current = initial;
+    typed.current = false;
+    setQ(initial);
+    setOpen(false);
+  }, [initial]);
 
   // Debounced so a fast typist makes one upstream call, not eight. The
   // AbortController matters more than the delay: without it a slow response