feat: duplicates resolve themselves without Lidarr (M502 #5517)

Lidarr is off, and with it the resolver had stopped merging: it only
merged when Lidarr had said which copies it mapped. Minstrel is now the
only program writing the library, so the rule is about the copies:

- A song held twice on one album: the extra copies merge into the one
  whose tags fit best (then lossless, larger, older).
- Across releases or under another title: when every copy but one is a
  video rip (held back, or named like one and not marked fine), the rips
  merge into the one that is not.
- Clean copies on different releases are linked as one song, as before.
- Anything else waits for the operator.

Gone with Lidarr: release switches and their settle window, the
unmapped-file read, the rip search, the merge guard and its 409/503,
lidarr.Client's release methods, and duplicate_group_members.lidarr_state
(migration 0078). The duplicates page drops the per-copy Lidarr badge
and the blocked-merge notice; past release changes stay in its history.

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

web/src/lib/components/FingerprintSettingsCard.svelte

@@ -120,10 +120,9 @@
       <span>
         <span class="text-sm text-text-primary">Resolve duplicates automatically</span>
         <span class="block text-xs text-text-secondary">
-          Merges copies Lidarr doesn't use into the one it does, and moves a Lidarr album off a
-          release that lists songs twice. A song kept on several releases counts as one song, and
-          video rips are kept out of radio and the mixes. A copy Lidarr uses is never removed.
-          Off, every group waits here for you.
+          Merges a song held twice on one album, and a video rip with a clean copy elsewhere, into
+          the copy that fits best. A song kept on several releases counts as one song, and video
+          rips are kept out of radio and the mixes. Off, every group waits here for you.
         </span>
       </span>
     </label>