fix(library): extract recording MBID → tracks.mbid; unblock LB similarity

tracks.mbid was 100% NULL: the scanner only extracted album + artist
MBIDs, never the recording MBID. The ListenBrainz similarity worker is
gated on tracks.mbid IS NOT NULL, so track_similarity could never
populate — starving For-You/radio's strongest candidate source
(lb_similar) on every library.

- mbids.go: add extractRecordingMBID (mbz.Recording / Picard
  musicbrainz_recordingid). Separate fn so extractMBIDs' signature +
  unit tests stay untouched.
- scanner.go: persist recording MBID via UpsertTrack (heals on the
  file_path conflict, so re-scans backfill for free).
- BackfillTrackMBIDs: one-shot pass mirroring BackfillMBIDs, wired as
  scan Stage 2b (idempotent via SetTrackMbidIfNull, gated by
  BackfillCap, log-only progress).
- migration 0029: tracks_mbid_unique (0002, written when the column
  was always NULL) wrongly assumes one MBID == one track. A recording
  appears on multiple releases, so rows legitimately share a recording
  MBID. Replace with a non-unique partial index. Zero-risk: column is
  100% NULL at migration time.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

internal/db/queries/tracks.sql

@@ -19,6 +19,22 @@ ON CONFLICT (file_path) DO UPDATE SET
     updated_at = now()
 RETURNING *;
 
+-- name: ListTracksMissingMbidWithPath :many
+-- Track recording-MBID backfill: tracks with NULL mbid that still have
+-- a file to re-read. $1 caps the batch (mirrors the album backfill).
+SELECT id, file_path
+  FROM tracks
+ WHERE mbid IS NULL
+ ORDER BY id
+ LIMIT $1;
+
+-- name: SetTrackMbidIfNull :exec
+-- Heal a track's recording MBID only while still NULL — idempotent, so
+-- re-running the backfill is a no-op for already-healed rows.
+UPDATE tracks
+   SET mbid = $2, updated_at = now()
+ WHERE id = $1 AND mbid IS NULL;
+
 -- name: GetTrackByID :one
 SELECT * FROM tracks WHERE id = $1;