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>

internal/server/server.go

@@ -57,17 +57,6 @@ func (a lidarrUnmonitorAdapter) UnmonitorTrack(ctx context.Context, trackMbid, a
 	return c.UnmonitorTrack(ctx, trackMbid, albumMbid)
 }
 
-// ListUnmappedTrackFiles lets the duplicate merge refuse to remove a copy
-// Lidarr maps (M498). tracks.ErrLidarrDisabled tells it there is no Lidarr to
-// protect.
-func (a lidarrUnmonitorAdapter) ListUnmappedTrackFiles(ctx context.Context) ([]lidarr.TrackFile, error) {
-	c := a.fn()
-	if c == nil {
-		return nil, tracks.ErrLidarrDisabled
-	}
-	return c.ListUnmappedTrackFiles(ctx)
-}
-
 // ScanTrigger is the subset of the scanner the HTTP handler needs. Kept as an
 // interface so tests can stub it without touching the DB. The progressCb
 // parameter (added in m7-scan-progress) lets the orchestrator drive partial-