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>

docker/worker/tasks.py

@@ -455,33 +455,34 @@ def rip_disc(self, device_path: str, job_id: str, target_dir: str = None):
     if ergebnis.get("status") == "error":
         fehler_text = ergebnis.get("error") or ""
         if "volume key is unknown" in fehler_text:
-            # Befund 25.07.2026, im Worker nachgemessen (Akira UHD, MKB v76,
-            # Pressung Dez. 2020): Laufwerk und MakeMKV sind in Ordnung —
-            # MakeMKV fragt online gar nicht erst nach einem Schlüssel, und
-            # der Online-Kanal liefert auch nichts mehr. Der alte Text hier
-            # ("Disc neuer als die Schlüssel-Datenbank, mit einem der
-            # nächsten Updates rippbar") war schlicht falsch und hat in die
-            # falsche Richtung geschickt. Details: makemkv_daten.py.
-            keydb = makemkv_daten.keydb_status()
+            # Befund 25.07.2026, auf BEIDEN Maschinen gemessen: Laufwerk und
+            # MakeMKV sind in Ordnung. makemkvcon unter Linux ruft die
+            # Disc-Schlüssel schlicht nie ab — die Windows-Version tut es
+            # (Meldung 3338). Hier stand vorher erst "Disc zu neu" und danach
+            # "der Schlüssel-Kanal ist tot"; beides war falsch und hat in die
+            # Irre geschickt. Herleitung im Kopf von makemkv_daten.py.
+            speicher = makemkv_daten.schluesselspeicher_status()
+            anzahl = speicher.get("schluessel", 0)
             ergebnis["error"] += (
                 " — Klartext: Laufwerk und Rippy sind in Ordnung, MakeMKV "
-                "liest die Disc. Es kennt nur den Schlüssel dieser Pressung "
-                "nicht und holt ihn auch nicht mehr online nach — MakeMKVs "
-                "Schlüssel-Kanal liefert nichts mehr (am 25.07.2026 im "
-                "Worker nachgemessen). Abhilfe: eine KEYDB.cfg unter "
-                "Einstellungen → System hochladen; sie wirkt ab dem nächsten "
-                "Rip. "
+                "liest die Disc. Es fehlt nur der Schlüssel dieser Pressung. "
+                "Der Grund: makemkvcon holt Schlüssel unter Linux nie selbst "
+                "nach — die Windows-Version schon. "
                 + (
-                    "Aktuell liegt dort keine KEYDB.cfg."
-                    if not keydb.get("vorhanden")
-                    else "Es liegt bereits eine KEYDB.cfg dort — sie kennt "
-                    "diese Pressung offenbar nicht; eine neuere Fassung "
-                    "kann helfen."
+                    "Dieser Worker kennt aktuell GAR KEINEN Disc-Schlüssel. "
+                    if not anzahl
+                    else f"Dieser Worker kennt {anzahl} Disc-Schlüssel, "
+                    "diese Pressung ist nicht dabei. "
                 )
-                + " Den AACS-Dump dieser Disc bewahrt Rippy jetzt dauerhaft "
-                "auf; er steht unter Einstellungen → System zum Download "
-                "bereit (für die Einreichung im MakeMKV-Forum, Bereich "
-                "'Ultra HD Blu-ray')."
+                + "Abhilfe: MakeMKV auf einem Windows-PC installieren, die "
+                "Disc dort einmal öffnen, dann die Datei _private_data.tar "
+                "aus dem MakeMKV-Datenverzeichnis unter Einstellungen → "
+                "System hochladen. Wirkt ab dem nächsten Rip. Klappt auch "
+                "das nicht, kennt MakeMKV die Pressung selbst nicht — dann "
+                "hilft nur eine KEYDB.cfg (ebenfalls dort hochladbar) oder "
+                "das Einreichen des AACS-Dumps im MakeMKV-Forum, Bereich "
+                "'Ultra HD Blu-ray'. Der Dump steht unter Einstellungen → "
+                "System zum Download bereit."
             )
         elif disc_type == "uhd" and "Failed to open disc" in fehler_text:
             ergebnis["error"] += (