feat(web): a playlist entry whose file is missing greys out and is skipped — #2527

The row treatment for a dead playlist entry already existed -- muted
text, no play on click, no drag, no kebab, never "now playing" -- but it
only fired for track_id === null, the track-deleted case. A missing file
kept a live-looking row that failed on click.

The behavioural gate now covers both, and the presentation distinguishes
them, because they mean different things to the person reading the list.
A removed track is gone for good and keeps the strikethrough. A missing
file is a track we still have -- history, likes, the lot -- whose bytes
aren't on disk right now, so it gets an explicit "File missing" and a
title explaining it stays in the playlist and comes back on its own if
the file does. A strikethrough there would claim it was deleted, which
is a lie about a file the scanner may well adopt back tomorrow (#2528).

Skipping routes through playlistTrackToRef, which already returned null
for removed tracks and whose callers already filter nulls. Adding the
unavailable check there means every queue builder -- PlaylistCard,
systemRefetch, the detail page -- skips a missing file without any of
them learning what missing_since is.

Remove stays available on a dead row: the owner must still be able to
take it out of their own list.

web/src/lib/api/types.ts

@@ -87,6 +87,12 @@ export type PlaylistTrack = {
   duration_sec: number;
   stream_url: string | null;
   added_at: string;
+  // True when the track still exists but its file is missing from disk
+  // (#2527). Distinct from track_id === null: that one is gone for good,
+  // this one keeps its play history and likes and may come back — the
+  // scanner un-marks it, or adopts it if it returns renamed. Both are
+  // unplayable; only this one is worth telling the user about.
+  unavailable: boolean;
 };
 
 export type PlaylistDetail = Playlist & {