deletePlaylist() schickte ein POST auf /api/v1/cloud/playlists. Der Server
unterscheidet dort nach Methode (POST = anlegen, DELETE = löschen), also
landete das Löschen im Anlegen-Handler, scheiterte an der leeren
Namensprüfung und lieferte HTTP 200 mit `status: error` zurück.
Zusätzlich wurde der Rückgabewert in cloud_screen.dart ignoriert: die UI
meldete "Playlist gelöscht", während die Playlist auf dem Server bestehen
blieb und beim nächsten Sync wieder auftauchte.
- cloud_service.dart: DELETE mit id im Body, Fehler werden geloggt
- cloud_screen.dart: Rückgabewert auswerten statt pauschal Erfolg melden
- cloud_service_test.dart: 3 Regressionstests (Methode ist DELETE, id im
Body, status != ok → false, Netzwerkfehler → false)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
## YT-Quell-URL (Server ist die Quelle)
- cloud_service.ytUrlSetzen(): POST /api/v1/cloud/yt-url (per-User UPDATE user_songs.yt_url)
- musik_scanner._sucheYtUrls(): durchsucht NUR Songs mit cloud_id, die auf dem Server noch keine yt_url haben; Treffer werden auf den Server hochgeladen statt lokal gespeichert
- db_helper: ytUrlAktualisieren/songsOhneYtUrl entfernt, songsMitCloudId() ergänzt
- download_service: yt_url wird beim Download nicht mehr lokal persistiert
## Fallback-Kette reDownload (korrupte/fehlende Datei)
- 1) Server-Download via cloud_id + Magic-Byte-Check (primäre Quelle)
- 2) Server-ytUrl (aus listSongs) → yt-proxy als letzte Chance
- 3) Legacy: lokal gespeicherte ytUrl (Bestandsdaten vor v2.52)
- song_tile: „Neu laden“ erscheint bei istKorrupt && (cloudId != null || ytUrl != null)
- 3 neue Tests (ytUrlSetzen: ok/error/401) → 111 Tests grün, analyze 0 Issues
