feat(backend): PO token provider for YouTube downloads; drop the cookies approach

Replace the cookies-file stopgap (needs a throwaway account + manual refresh)
with a self-hosted PO token provider — the cookie-less way past YouTube's
datacenter-IP block (bot check + media 403).

- docker-compose: new bgutil-provider service (brainicism/bgutil-ytdlp-pot-provider)
  + install the bgutil-ytdlp-pot-provider plugin in the backend + POT_PROVIDER_URL
  env + depends_on.
- ytdlp.js / server.js: when POT_PROVIDER_URL is set, pass
  --extractor-args youtubepot-bgutilhttp:base_url=... to the download cascade, the
  YTM search probe and the importer resolve. Empty → omitted (unchanged behaviour).
- Removed the cookiesFile config + --cookies wiring so there's no dead code.

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

CHANGELOG.md

@@ -88,11 +88,15 @@ to Android at parity with web, and fixes a batch of same-name-artist and player
   as avatar chips, matching the Android app (previously plain text).
 
 ### Fixed
-- **Downloads — YouTube bot check ("Sign in to confirm you're not a bot")** — YouTube now blocks
-  yt-dlp from datacenter IPs. The backend passes a **cookies file** to every yt-dlp call when present
-  (`YTDLP_COOKIES`, default `/data/youtube-cookies.txt`): drop a Netscape `cookies.txt` from a
-  logged-in (ideally throwaway) account into the data volume and downloads/search/resolve
-  authenticate again. Absent → yt-dlp runs exactly as before (no behaviour change).
+- **Downloads — YouTube datacenter-IP block (bot check + media 403)** — YouTube now blocks yt-dlp
+  from datacenter IPs (first "Sign in to confirm you're not a bot", then `HTTP 403` on the media
+  stream, which needs a **PO token** yt-dlp can't compute itself). Added a **`bgutil-provider`**
+  service (Docker) + the `bgutil-ytdlp-pot-provider` plugin in the backend; yt-dlp fetches PO tokens
+  from it — no cookies or account needed. Guarded by `POT_PROVIDER_URL` (empty → yt-dlp runs exactly
+  as before). See `docker-compose.yml`.
+- **Downloads — a failed direct-link download reported success** — the direct-URL path returned
+  `success` even when no audio was produced (e.g. the YouTube 403), so the job showed "Fertig!" and
+  the UI (web + Android) said the track was added. It now reports failure with a clear message.
 - **Artist pin — search & similar artists (Web + Android)** — a pinned artist now shows the correct
   Deezer photo in library search (not the wrong same-name person's), and its "Similar Artists" use
   Deezer's **related** for the pinned artist instead of Last.fm's list (which was keyed to the