fix(android): große Offline-Downloads laufen jetzt bis zum Ende

WorkManager stoppt einen Hintergrund-Worker nach ~10 Minuten (ein
Vordergrunddienst scheidet aus, FOREGROUND_SERVICE_TYPE_DATA_SYNC stürzt
unter Android 15 ab). Der Worker prüfte nie isStopped, lief blind weiter
und meldete Result.failure() ohne Backoff — WorkManager startete nichts
neu, bei 1900 Titeln musste man wiederholt von Hand antippen.

Jetzt: sauberer Ausstieg bei isStopped mit Result.retry() und linearem
Backoff, Selbst-Fortsetzung solange Titel offen sind (max. 20 Versuche,
damit dauerhaft kaputte Titel keine Endlosschleife auslösen), Retry statt
Failure im äußeren catch, und beim App-Start werden unvollständige
Gruppen weitergeführt.

Dazu: die Zahl offener Titel kam aus einer Abfrage pro Titel am Ende
jedes Laufs — jetzt ein einzelnes COUNT mit JOIN.

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

CHANGELOG.md

@@ -108,6 +108,25 @@ Die Android-App zählt eigenständig weiter (mehrere APKs pro Release). Welche d
   toter Zurück-Druck gleich zu Beginn. Vorwärts funktioniert unverändert (mitgetestet).
 
 ### Fixed
+- **Große Offline-Downloads liefen nie zu Ende (Android)** — WorkManager räumt einem
+  Hintergrund-Worker rund **10 Minuten** ein und stoppt ihn dann. Ein Vordergrunddienst ist keine
+  Option, `FOREGROUND_SERVICE_TYPE_DATA_SYNC` bringt die App unter Android 15 zum Absturz. Der
+  Downloader prüfte aber nie `isStopped`, lief nach dem Stoppsignal blind weiter bis zum harten
+  Abbruch, und meldete am Ende `Result.failure()` statt `Result.retry()` — ohne Backoff. WorkManager
+  startete deshalb **nichts** von allein neu: bei 1900 Titeln musste man immer wieder von Hand auf
+  Herunterladen tippen. Jetzt:
+  - die Schleife steigt bei `isStopped` sauber aus und fordert den nächsten Lauf an (`Result.retry()`,
+    linearer Backoff 30 s). Fertige Titel überspringt sie ohnehin, es wird also fortgesetzt statt neu
+    geladen.
+  - bleiben danach noch Titel offen, fordert der Worker selbst weitere Läufe an — begrenzt auf 20
+    Versuche, damit dauerhaft kaputte Titel (auf dem Server gelöscht, immer 404) keine Endlosschleife
+    auslösen. Danach steht in der Gruppenzeile weiter `x/y Titel`, und ein Tipp startet die Kette neu.
+  - ein einzelner Netzfehler beendete bisher die **ganze** Kette endgültig (`Result.failure()` im
+    äußeren `catch`); jetzt wird auch das wiederholt.
+  - beim App-Start werden unvollständige Gruppen weitergeführt (`setzeUnvollstaendigeFort()`), falls
+    die Kette doch einmal reißt — Geräteneustart, aufgebrauchte Versuche.
+  - Nebenbei: die Zahl der offenen Titel kam aus einer Abfrage **pro Titel** am Ende jedes Laufs
+    (1900 Stück); jetzt eine einzige `COUNT`-Abfrage mit JOIN.
 - **Große Offline-Playlists ließen sich nicht abspielen (Android)** — bei ~100 Titeln ging alles, bei
   1900 nicht. Ursache war nicht die Größe an sich: die Warteschlange wurde aus **allen** Titeln der
   Gruppe gebaut, ohne Rücksicht auf den Download-Zustand. Die Karte, aus der die lokale Datei kommt,