fix(uhd): 4K-UHD geloest - makemkvcon holt Schluessel unter Linux nie

Richtigstellung des Vortags-Befunds. Dort stand, MakeMKVs Schluessel-Kanal
sei abgeschaltet. Das war FALSCH: die Herleitung stuetzte sich auf zwei
Hostnamen aus alten Forumsbeitraegen (hkdata.fairuse.org,
hkdata.crabdance.com), die zwar wirklich nicht mehr aufloesen, von MakeMKV
aber laengst nicht mehr benutzt werden. Aufgedeckt durch den Einwand des
Commanders, unter Windows ginge es sofort.

Gegenprobe mit demselben Laufwerk und derselben Disc (Akira UHD, MKB v76):

                        Linux (Worker)      Windows
  Verbindungen          KEINE EINZIGE       185.84.108.20:443
  Meldung 3338          nie                 "Downloading latest HK"
  _private_data.tar     2048 B, 0 Keys      6,4 MB, 604 Keys
  Disc                  volume key unknown  TCOUNT:5, geht auf

Gegengeprueft mit leerem UND gefuelltem Speicher, mit und ohne --noscan,
mit dev:/dev/sr0 und disc:0, mit geloeschter update.conf. Linux fragt nie.
Die Meldungsvorlage "Downloading latest %1 to %2 ..." steckt sehr wohl im
Linux-Binary - sie loest nur nicht aus. Gleiches Symptom im MakeMKV-Forum,
seit Jahren offen (t=25782, t=34022). Der Dienst lebt; der Worker erreicht
185.84.108.20:443 sogar problemlos.

BEWIESEN: Nach Uebernahme des Windows-Schluesselspeichers oeffnet
makemkvcon auf der VM die Akira-UHD - "Operation successfully completed",
TCOUNT:5, fuenf Titel, identisch zum Windows-Ergebnis. Erster belegter
UHD-Disc-Zugriff auf der Rippy-Maschine.

- makemkv_daten.py (beide Zwillinge): zaehle_schluessel,
  private_data_pruefen, schluesselspeicher_status, private_data_schreiben.
  Die Pruefung lehnt einen Speicher OHNE hkd_*.bin ab - sonst laedt jemand
  den leeren Vorrat einer frischen Installation hoch, nichts aendert sich,
  und niemand versteht warum. Modulkopf komplett neu, inkl. der
  Fehldiagnose als Warnung fuer spaeter.
- API: GET/POST /system/keystore. Der Rohkoerper der Anfrage IST die Datei
  (binaer - JSON/Base64 waere Ballast, Multipart kann die API nicht).
  Groessengrenze 64 MB = client_max_body_size in nginx.conf.
- UI: neuer Block "Disc-Schluessel fuer 4K-UHD" UEBER dem KEYDB-Block, mit
  Schluessel-Anzahl, Upload und Anleitung fuer den Windows-Weg. KEYDB.cfg
  ist jetzt als Notnagel beschriftet. Worker-Plakette zeigt die Anzahl;
  0 heisst sichtbar "4K-UHD scheitert".
- tasks.py: UHD-Fehlertext sagt den Windows-Weg an und nennt die Anzahl
  bekannter Schluessel dieses Workers.
- caps.py meldet schluessel je Worker.
- Alle Falschaussagen korrigiert: UI (3), Anleitung (2), README (3),
  KONZEPT §8 + §10, Worker-Dockerfile, makemkv_key.py (dort stand "Den
  AACS-Schluessel zieht MakeMKV via LibreDrive ohnehin selbst aus dem
  Laufwerk" - gilt fuer Blu-ray, NICHT fuer UHD).
- SAVEPOINT v3.11, ROADMAP Etappe 18 (Etappe 17 mit Nachtrag), AGENTS.

Offen: voller UHD-Rip inkl. Transcode-E2E; und ob sich der Abruf unter
Linux doch anstossen laesst.

Quellen (AGENTS Regel D):
- Linux laedt keine Hashed Keys, gleiches Symptom:
  https://forum.makemkv.com/forum/viewtopic.php?t=25782
  https://forum.makemkv.com/forum/viewtopic.php?t=34022
- Schluessel als hkd_*.bin in _private_data.tar:
  https://forum.makemkv.com/forum/viewtopic.php?t=32675
- Meldungsformat: https://www.makemkv.com/developers/usage.txt

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

README.md

@@ -78,18 +78,26 @@ NICHT als emuliertes CD-ROM (`media=cdrom`), das kann keine SCSI-Kommandos.
    (MakeMKV-Forum: „Ultimate UHD Drives Flashing Guide") **und** einen
    passenden Disc-Schlüssel. Normale BD/DVD gehen mit jedem Laufwerk und
    ohne Schlüssel-Datei.
-   **Der Schlüssel ist heute die eigentliche Hürde.** Am 25.07.2026 auf
-   der Rippy-VM gemessen (Akira UHD, MKB v76, Pressung Dezember 2020):
-   Laufwerk und MakeMKV waren in Ordnung — „Using LibreDrive mode
-   (v06.3)", die Disc wurde gelesen — und trotzdem kam „The volume key is
-   unknown for this disc". MakeMKV versucht dabei **gar nicht mehr**,
-   online einen Schlüssel zu holen, und die früher genutzten
-   Schlüssel-Server (`hkdata.fairuse.org`, `hkdata.crabdance.com`) lösen
-   weltweit nicht mehr auf. Ein MakeMKV-Update ändert daran nichts.
-   Der einzige Weg, der heute funktioniert, ist eine Datei **`KEYDB.cfg`**
-   (GROSS geschrieben — Linux unterscheidet Groß- und Kleinschreibung) im
-   MakeMKV-Datenverzeichnis. Die legst du unter **Einstellungen → System**
-   ab (siehe unten).
+   **Der Schlüssel ist heute die eigentliche Hürde — und zwar aus einem
+   überraschenden Grund.** Am 25.07.2026 auf beiden Maschinen gemessen
+   (Akira UHD, MKB v76, Pressung Dezember 2020): Laufwerk und MakeMKV
+   waren in Ordnung — „Using LibreDrive mode (v06.3)", die Disc wurde
+   gelesen — und trotzdem kam „The volume key is unknown for this disc".
+   Die Ursache:
+   **`makemkvcon` unter Linux holt Disc-Schlüssel nie aus dem Netz. Die
+   Windows-Version tut es.**
+   Gemessen: Linux baute in keinem einzigen Lauf eine Verbindung nach
+   draußen auf — geprüft mit leerem und mit gefülltem Schlüsselspeicher,
+   mit und ohne `--noscan`, mit `dev:` und `disc:`, und mit erzwungener
+   frischer Prüfung. Dieselbe Disc am selben Laufwerk unter Windows: „Lade
+   aktuelle HK …", Verbindung zum Schlüssel-Server, Disc geht auf.
+   Ein MakeMKV-Update ändert daran nichts, und es ist kein Fehler in
+   Rippy.
+   **Der Weg drumherum:** MakeMKV einmal auf einem Windows-PC die Disc
+   öffnen lassen und die dabei gefüllte Datei `_private_data.tar` bei
+   Rippy unter **Einstellungen → System** hochladen (siehe unten). Für
+   Pressungen, die auch MakeMKV nicht kennt, bleibt die **`KEYDB.cfg`**
+   als Notnagel.
    ⚠️ **Rippy liefert keine Schlüssel mit, lädt keine herunter und
    verteilt keine.** Rippy stellt nur den Platz für eine Datei bereit, die
    du selbst mitbringst, und zeigt dir ehrlich an, was dort liegt.
@@ -131,26 +139,35 @@ MakeMKV-Beta-Key (wechselt ~monatlich, Forum-Thread t=1053) wird hier im
 UI eingetragen und gilt ab dem **nächsten Rip** — ohne Rebuild, ohne
 Neustart; er schlägt den Key aus der `.env`.
 
-**Disc-Schlüssel (`KEYDB.cfg`)** — im selben Tab, nur für 4K-UHD nötig:
+**Disc-Schlüssel für 4K-UHD** — im selben Tab, nur für UHD nötig. Der
+Hauptweg zuerst:
 
-- **Status**: Rippy zeigt, ob eine `KEYDB.cfg` im MakeMKV-Datenverzeichnis
-  liegt, mit Pfad, Größe, Anzahl der Disc-Einträge und Änderungsdatum.
-- **Hochladen**: Knopf „KEYDB.cfg hochladen", dann deine eigene Datei im
-  Datei-Dialog auswählen — mehr ist nicht zu tun. Rippy prüft den Inhalt
-  auf Plausibilität und lehnt Unsinn (leere Datei, versehentlich geladene
-  HTML-Fehlerseite) mit einer deutschen Klartext-Meldung ab, statt ihn
-  stillschweigend zu speichern.
-- **Entfernen**: ein Knopf, die Datei ist wieder weg.
+- **Schlüsselspeicher (`_private_data.tar`)**: Rippy zeigt, **wie viele
+  Disc-Schlüssel** dieser Worker kennt. Steht dort 0, scheitert jede
+  unbekannte UHD-Disc.
+  **So füllst du ihn:** MakeMKV auf einem Windows-PC installieren
+  (gleicher Beta-Key), Laufwerk anstecken, Disc einmal öffnen — dabei lädt
+  MakeMKV die Schlüssel nach. Dann in MakeMKV unter *Preferences →
+  General* das „MakeMKV data directory" nachschlagen und die Datei
+  `_private_data.tar` daraus hier hochladen. Wirkt ab dem nächsten Rip;
+  für neue Discs gelegentlich wiederholen.
+  Rippy prüft die Datei und lehnt sie ab, wenn kein einziger Schlüssel
+  drinsteckt — sonst ändert sich nichts und niemand versteht, warum.
+- **`KEYDB.cfg`** (Notnagel): nur nötig, wenn eine Pressung auch mit
+  gefülltem Speicher nicht aufgeht, MakeMKV sie also selbst nicht kennt.
+  Hochladen, Status und Entfernen genau wie oben.
 - **AACS-Dumps herunterladen**: MakeMKV legt bei jeder unbekannten Disc
   selbst einen Dump ab. Genau den braucht man, wenn man im MakeMKV-Forum
   um den Schlüssel für eine neue Pressung bittet — hier holst du ihn dir
   aus dem Container, ohne SSH.
 
-Der Beta-Key ist die **Lizenz für die Software**; die `KEYDB.cfg` sind
-**Disc-Schlüssel** — zwei völlig verschiedene Dinge. **Rippy liefert und
-lädt keine Disc-Schlüssel**, es hält nur ein persistentes Verzeichnis
-dafür bereit (`MAKEMKV_DATA_HOST`, siehe Tabelle unten) — rebuild-fest,
-damit deine Datei einen `docker compose build` überlebt.
+Der Beta-Key ist die **Lizenz für die Software**, der Schlüsselspeicher
+und die `KEYDB.cfg` sind **Disc-Schlüssel** — zwei völlig verschiedene
+Dinge. **Rippy liefert und lädt keine Disc-Schlüssel**, es hält nur ein
+persistentes Verzeichnis dafür bereit (`MAKEMKV_DATA_HOST`, siehe Tabelle
+unten) — rebuild-fest, damit deine Dateien einen
+`docker compose build` überleben. Der Schlüsselspeicher ist der
+Zwischenspeicher **deiner eigenen** MakeMKV-Installation.
 
 **Updates:** „Auf Updates prüfen" vergleicht mit makemkv.com und den
 offiziellen HandBrake-Releases (12 h gecacht). MakeMKV-Update ohne
@@ -158,10 +175,11 @@ Code-Änderung: `MAKEMKV_VERSION=x.y.z` in die `.env`, dann
 `docker compose build worker && docker compose up -d worker`.
 ⚠️ **Richtigstellung (25.07.2026):** Hier stand früher, neue MakeMKV-
 Versionen brächten „auch die neueste Disc-Schlüssel-Datenbank mit". Das
-ist widerlegt — auf der VM nachgemessen: MakeMKV holt für eine unbekannte
-UHD-Disc keinen Schlüssel mehr, weder mitgeliefert noch aus dem Netz. Ein
-Update lohnt für Programmfehler und neue Laufwerke, hilft aber NICHT
-gegen „The volume key is unknown". Dafür brauchst du die `KEYDB.cfg`.
+ist widerlegt — MakeMKV liefert überhaupt keine Disc-Schlüssel mit, es
+holt sie zur Laufzeit. Und die Linux-Version holt sie nie. Ein Update
+lohnt für Programmfehler und neue Laufwerke, hilft aber NICHT gegen „The
+volume key is unknown". Dafür brauchst du den Schlüsselspeicher (siehe
+oben).
 HandBrake kommt im Docker-Worker bewusst aus Debian (stabil, hinkt der
 offiziellen Version hinterher); der native Windows-Worker nutzt die
 aktuelle Version direkt.
@@ -196,7 +214,7 @@ bleibt All-in-one.
 | `THETVDB_API_KEY` | optional | Serien-Fallback |
 | `MAKEMKV_APP_KEY` | optional | MakeMKV-Beta-Key (Forum); DVDs gehen ohne — bequemer: im UI unter Einstellungen → System pflegen |
 | `MAKEMKV_URL_BASE` | optional | alternative Download-Quelle für den Image-Build |
-| `MAKEMKV_DATA_HOST` | optional | Host-Verzeichnis für MakeMKVs Daten (Default `/srv/rippy/makemkv`) — hier liegen deine `KEYDB.cfg` und die AACS-Dumps; persistent, überlebt jeden Rebuild |
+| `MAKEMKV_DATA_HOST` | optional | Host-Verzeichnis für MakeMKVs Daten (Default `/srv/rippy/makemkv`) — hier liegen dein Schlüsselspeicher `_private_data.tar`, eine etwaige `KEYDB.cfg` und die AACS-Dumps; persistent, überlebt jeden Rebuild |
 | `OPTICAL_SR` | je Host | Host-Pfad des CD-ROM-Knotens (Default `/dev/sr0`) — siehe „Laufwerk anpassen" |
 | `OPTICAL_SG` | je Host | Host-Pfad des sg-Knotens des Laufwerks (Default `/dev/sg1`; oft `/dev/sg0`) |
 | `POSTGRES_PASSWORD` | optional | DB-Passwort (Default `rippy`) — für exponierte Umgebungen ein starkes Passwort setzen |
@@ -228,8 +246,9 @@ Voraussetzungen auf dem Ziel-Host:
 4. MakeMKV-Datenverzeichnis anlegen: `mkdir -p /srv/rippy/makemkv` (oder
    eigenen Pfad über `MAKEMKV_DATA_HOST` in der `.env`). Dort liegen
    MakeMKVs Programmzustand, die AACS-Dumps und — falls du 4K-UHD rippst —
-   deine eigene `KEYDB.cfg`. Das Verzeichnis gehört dem Host, damit ein
-   `docker compose build` deine Datei nicht wegwirft.
+   dein Schlüsselspeicher (`_private_data.tar`) sowie eine etwaige
+   `KEYDB.cfg`. Das Verzeichnis gehört dem Host, damit ein
+   `docker compose build` deine Dateien nicht wegwirft.
 
 Dann wie im Schnellstart: klonen, `.env` füllen, `docker compose up -d
 --build`, `http://<host>` öffnen — der Einrichtungs-Assistent führt durch