feat: video rips and stray copies handle themselves (M498 #5439)

- The resolver also merges cross-release and mismatch groups where Lidarr
  maps exactly one copy: the others fulfil nothing, so removing them opens no
  hole (D-a rule 1). That covers a rip beside the clean copy on another
  release and a wrong-file import Lidarr holds unmapped. With two or more
  mapped copies each fulfils its own release and nothing is removed.
- A track whose file name carries a video-rip marker is held back from radio
  and the system mixes (tracks.source_verdict, migration 0077). It still plays
  when chosen. A renamed file is released; the operator's "fine" sticks.
- Suspect sources shows what was done to each track, with "This one is fine"
  and "Hold back again" (PUT /api/admin/library/suspect-sources/{id}).
- The Liked list prefers a copy that is not held back.

Replacing a rip that has no clean copy is left for the operator to decide.

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

internal/db/queries/likes.sql

@@ -20,14 +20,15 @@ DELETE FROM general_likes
 RETURNING track_id;
 
 -- name: ListLikedTrackRows :many
--- One row per liked song: of its copies, the one present on disk, then the
--- one liked first.
+-- One row per liked song: of its copies, the one present on disk, then one
+-- that is not a held-back video rip, then the one liked first.
 SELECT t.* FROM tracks t
 JOIN (SELECT DISTINCT ON (lt.song_key) l.track_id, l.liked_at
         FROM general_likes l
         JOIN tracks lt ON lt.id = l.track_id
        WHERE l.user_id = $1
-       ORDER BY lt.song_key, (lt.missing_since IS NOT NULL), l.liked_at, lt.id) l
+       ORDER BY lt.song_key, (lt.missing_since IS NOT NULL),
+                (lt.source_verdict IS NOT DISTINCT FROM 'suspect'), l.liked_at, lt.id) l
   ON l.track_id = t.id
 ORDER BY l.liked_at DESC, t.id
 LIMIT $2 OFFSET $3;