fix: a group of one recording in several slots is settled by getting the album again, not merged (#6184)

The duplicates review offered only Merge for a wrong-slot group. A merge keeps
one copy's title whether or not it is the audio's, and neither sets the release
aside nor wants the missing song back.

For class mismatch the page now asks which song the recording is. "Get it
again" (the operator can't tell) removes every copy; "Keep <title>" keeps that
copy and removes the ones under other titles. Either way it runs the resolver's
own path: the release the files came from is set aside, the removed copies'
tracks stay marked missing and emptied, and the album is wanted again.

- library.SettleWrongSlot, POST /api/admin/library/duplicates/{id}/refetch
- ListDuplicateGroupsForResolve takes an optional group_id
- removeWrongSlots takes the acting operator (manual: not automatic, actor in
  the audit row) and removes files through removeTrackFileOnDisk, so a
  read-only library answers library_not_writable

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

internal/db/queries/duplicates.sql

@@ -197,7 +197,8 @@ UPDATE duplicate_groups
 -- tags or the library listing's match; '' when neither names one.
 -- acoustid_state and acoustid_recording are what AcoustID said of the file,
 -- when it was looked up (#6169: which song one recording cut to several slots
--- is).
+-- is). group_id narrows it to one group, for the operator settling it (#6184);
+-- NULL reads them all.
 SELECT g.id                  AS group_id,
        g.tier,
        g.worst_bit_error_rate,
@@ -232,6 +233,7 @@ SELECT g.id                  AS group_id,
   LEFT JOIN track_acoustid_lookups l ON l.track_id = t.id
  WHERE g.status = 'pending'
    AND t.missing_since IS NULL
+   AND (sqlc.narg(group_id)::uuid IS NULL OR g.id = sqlc.narg(group_id)::uuid)
  ORDER BY g.id, t.id;
 
 -- name: SetDuplicateGroupClasses :exec