[Hellraiser28]

Closes #42.

Adds a Look up on MusicBrainz action to the bulk action bar. The bar sits on the song table that every view uses, so the lookup works the same in folders, smart playlists and recently played - including "select entire folder / smart playlist", which the server resolves like the other bulk actions.

How it works

1. Search the release once, by album and album artist. Both are prefilled with the values most of the selected songs share. The results show year, country, media (e.g. 2×CD), track count, label / catalog number and barcode, so editions can be told apart.

2. Match the songs to the release's tracks, the way Picard does for a known album:

   • disc and track number first
   • then title, ignoring case, accents, punctuation and bracketed additions such as "(Remastered 2011)"
   • then length, within 3 seconds and never when two tracks are equally close

   A number is not trusted when title and length both disagree (another edition of the album). A badge shows how each match was found. Every match can be changed by hand, and every song can be left out.

3. Choose the fields: the same ones as the single-song lookup except genre, which the release lookup does not return. Optionally the release's front cover is written to all songs; it is fetched once.

4. Apply goes through the existing bulk confirm dialog with its progress bar and the bulk summary. Each song gets its own track's values, and only fields that actually change are written, so the history lists real changes only.

Implementation

• GET /api/musicbrainz/releases - release search (release: + artist:).
• GET /api/musicbrainz/release/[id]/tracks - every track of a release with the tags it would write, via a new mapReleaseTracks() on top of mapToSongMetadata(). The track's own position and its artist credit win, which matters for compilations and for a recording that appears twice on a release.
• POST /api/songs/bulk/musicbrainz/songs - resolves the bulk target and returns the fields needed for matching and comparing (at most 500 songs, since they are matched against a single release).
• PATCH /api/songs/bulk/musicbrainz/apply - NDJSON stream like the other bulk routes. Each item carries its own metadata, which is checked against MUSIC_BRAINZ_FIELDS.
• Matching and building the writes are pure functions in src/features/musicbrainz/bulk-lookup.ts, with tests.
• Strings in all five locales. es, ca and fr are my drafts in the wording those files already use - happy to take corrections.

Tested

• vitest run: 317 tests pass, 15 of them new, for the matching, the comparison of current values, building the writes and validating an apply request.
• eslint clean on all new and changed files.
• tsc: only the two existing errors in detail-panel-preview-card.tsx, the same as on main.
• prettier: clean for the new files and the changed lines. bulk-action-bar.tsx, bulk-action-bar-pill.tsx and songs.repository.ts were already flagged on main, so I only formatted my own lines there.
• Docker build of the branch, tried in the browser against the real MusicBrainz with four test files that look like the first four tracks of Radiohead's OK Computer, tagged on purpose so that every kind of match is needed:
  • "Airbag" (track 1) and "Exit Music" (track 4) matched by number
  • "paranoid android" without a track number matched by title
  • a file without any tags matched by length to "Subterranean Homesick Alien"
• All Folders, "Select all songs": picked the 1997 UK CD; all four songs were written with title, artist, album artist, year, track/total, disc/total, label, catalog number, release type, barcode and original release date, plus the cover. The history lists exactly those changes.
• The same lookup again: every row says "Already up to date" and there is nothing to apply. The stored original release date compares as equal too.
• A smart playlist, "Select entire smart playlist": picked the 2016 XL Recordings reissue; only year, label, catalog number and barcode changed, on all four songs.
• German UI checked as well. A file the server cannot write is reported per song like in the other bulk actions; I saw that when my test files were still read-only for the container.