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>

web/src/lib/styles/error-copy.json

@@ -48,6 +48,8 @@
   "survivor_not_in_group": "That copy isn't part of this group any more.",
   "copy_tracked_by_lidarr": "Lidarr uses a copy this would remove, and would download it again. Keep that copy instead.",
   "lidarr_unavailable": "Lidarr didn't answer, so it isn't safe to remove a copy yet. Try again shortly.",
+  "suspect_track_not_found": "That track isn't flagged any more. Refresh the list.",
+  "invalid_verdict": "That isn't a choice for a flagged track.",
   "invalid_setting": "That setting is out of range.",
   "invalid_public_url": "That address isn't valid.",
   "album_not_found": "That album no longer exists.",