Add Lidarr as a download provider

[Gabriel-Lewis]

Ports upstream PR LumePart#21 (avedor + LumePart, 29 commits) onto this fork. Merged as a branch rather than reimplemented, so future upstream updates to that PR can be pulled in cleanly and author attribution is preserved.

Upstream LumePart#21 is open and actively maintained — not rejected. The maintainer's most recent comment on it is "Current state is working for me"; it has been gated mainly on Lidarr's own MusicBrainz metadata service being unreliable through much of 2025.

What this adds

• src/downloader/lidarr.go (new, ~740 lines) — raw HTTP client, X-Api-Key auth. An SDK-based approach was deliberately abandoned upstream at the maintainer's request.
  Endpoints used: GET /api/v1/rootfolder, GET /api/v1/album/lookup, GET|POST /api/v1/album, POST|GET /api/v1/command (AlbumSearch), GET /api/v1/track, GET /api/v1/queue, GET /api/v1/history, DELETE /api/v1/queue/{id}.
• Monitor interface gains MoveDownload(...), moving it off DownloadClient onto each provider. FileStatus gains QueueID. Status map keys move from track.File to track.ID, because Lidarr exposes no stable filename until import. slskd.go re-gains MoveDownload as a method (pure relocation); youtube.go gets a no-op stub.
• Config: LIDARR_URL, LIDARR_API_KEY, LIDARR_ROOT_FOLDER (default Music), LIDARR_RETRY (8), LIDARR_TIMEOUT (20), LIDARR_DIR, LIDARR_MIGRATE_DOWNLOADS, LIDARR_MONITOR_INTERVAL (1 min), LIDARR_MONITOR_DURATION (20 min).
• Album/track bridging: models.Track gains AlbumID. An album cache keyed by artist|album resolves a release-group MBID via /album/lookup, adds the album with searchForNewAlbum: true, then matches individual tracks back out of /api/v1/track and /api/v1/history by MBID or fuzzy title.
• Wizard gets a Lidarr section; defs.AllConfigKeys gains the Lidarr keys.

Verified

• go build ./src/main/ — succeeds.
• npm run build in src/web/frontend — succeeds.
• Merge is conflict-free against dev, and confirmed not to regress the #214 authbypass work that landed on dev after Add lidarr as downloader LumePart/Explo#21 last synced (git diff dev..HEAD -- src/web/backend/auth/ is empty).
• Two fixes I expected to need post-merge — adding Lidarr to needsDownloadDir() and running Lidarr.URL through fixBaseURL() in CommonFixes() — are already handled inside Add lidarr as downloader LumePart/Explo#21.

Not tested against a live Lidarr instance.

Tradeoff

Lidarr acquires whole albums only. A 25-track ListenBrainz playlist spans roughly 25 distinct albums, so putting lidarr first pulls far more audio than the playlist needs. That is inherent to Lidarr and accepted upstream — and it is the motivation for the fallback-threshold work stacked on top of this branch.

Note also that Lidarr.MoveDownload is a no-op: Lidarr places files itself, into its own root folder, not Explo's DOWNLOAD_DIR. LIDARR_ROOT_FOLDER must therefore resolve to the same music root Plex indexes.