feat(uhd): KEYDB.cfg-Unterstuetzung - MakeMKVs Schluessel-Kanal liefert nichts mehr

4K-UHD scheiterte an "The volume key is unknown for this disc". Am 25.07.2026
im Worker-Container nachgemessen: Laufwerk und MakeMKV sind in Ordnung
(LibreDrive v06.3 / Meldung 1011, Disc wird gelesen, AACS-Dump geschrieben) -
MakeMKV versucht gar nicht erst, online einen Schluessel zu holen. Belege:
_private_data.tar enthaelt nur die Index-Datei und KEINE hkd_*.bin; auch mit
geloeschter update.conf (Meldung 5074 belegt den Web-Kontakt) und mit
app_UpdateEnable="1" kam keiner; hkdata.fairuse.org und hkdata.crabdance.com
loesen weltweit nicht mehr auf (NXDOMAIN gegen Fritz!Box, 8.8.8.8, 1.1.1.1).
Betroffen war Akira UHD (MKB v76, Pressung Dez. 2020) - also gerade KEINE
Neuerscheinung. Der bisherige Fehlertext ("Disc neuer als die
Schluessel-Datenbank, mit einem der naechsten Updates rippbar") war falsch.

Einziger heute funktionierender Weg ist eine vom Nutzer selbst mitgebrachte
KEYDB.cfg. Rippy liefert KEINE Schluessel mit, laedt keine herunter und
verteilt keine - es stellt nur den Platz bereit und zeigt an, was dort liegt.

- Datenverzeichnis persistent gemountet (MAKEMKV_DATA_HOST, Default
  /srv/rippy/makemkv): KEYDB.cfg und AACS-Dumps ueberleben jeden Rebuild.
  Vorher loeschte jeder "up -d --build" beides - inklusive des Dumps, auf den
  die Fehlermeldung selbst verwies.
- entrypoint.sh und tasks.py schreiben settings.conf ergaenzend statt
  zerstoerend. Der entrypoint bricht bei nicht beschreibbarem Verzeichnis
  nicht mehr ab - mit "restart: unless-stopped" waere das ein Crashloop
  gewesen, in dem auch reines DVD-Rippen tot ist.
- Neues Zwillings-Modul makemkv_daten.py (docker/api + docker/worker,
  byteweise identisch; test_zwillinge_sind_byteweise_identisch wacht darueber
  und wurde durch absichtliches Verstellen als wirksam nachgewiesen).
- API: GET/POST/DELETE /system/keydb, GET /system/aacs-dumps(/{dateiname}).
  JSON-Body statt Multipart - python-multipart ist bewusst nicht installiert
  und wuerde die API beim Import toeten. nginx client_max_body_size 64m,
  sonst scheitert der Upload mit 413, bevor die API ihn sieht.
- UI (Einstellungen -> System): Status, Hochladen per Datei-Dialog, Entfernen,
  Dump-Download, KEYDB-Plakette je Worker (nur wo das Verzeichnis wirklich
  gemountet ist - ein Remote-Transcode-Worker truege sonst eine Warnung,
  die ihn nichts angeht).
- parse_msg() + log_cb: MakeMKV-Meldungen landen im Rippy-Log (gedrosselt:
  Code 1003 raus, keine Wiederholungen, max. 40 je Rip). Nebenbei behoben:
  der alte Parser (split(",", 4)[3]) schnitt jede Meldung am ersten Komma ab.
- Fuenf Stellen richtiggestellt, die behaupteten, MakeMKV-Updates braechten
  die neueste Disc-Schluessel-Datenbank mit (UI, Anleitung, README,
  Worker-Dockerfile, makemkv_key.py).

NICHT bewiesen: ein erfolgreicher UHD-Rip - es lag keine KEYDB.cfg mit dem
Akira-Schluessel vor. Belegt sind der Befund und die neue Mechanik. So steht
es auch im SAVEPOINT und in der ROADMAP.

Quellen (AGENTS Regel D):
- Datenverzeichnis + Dateiname GROSS/case-sensitiv:
  https://forum.makemkv.com/forum/viewtopic.php?t=30636
- hkd_*.bin in _private_data.tar:
  https://forum.makemkv.com/forum/viewtopic.php?t=32675
- headless settings.conf / app_UpdateEnable:
  https://forum.makemkv.com/forum/viewtopic.php?t=20364
- KEYDB.cfg-Zeilenformat (libaacs):
  https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg
- MSG-/PRGV-Format: https://www.makemkv.com/developers/usage.txt

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

docker/ui/src/pages/Anleitung.tsx

@@ -134,12 +134,15 @@ export default function AnleitungPage() {
           Einstellungen → System eintragen — gilt ab dem nächsten Rip, ohne Neustart. DVDs gehen
           immer auch ohne Key. Dort stehen auch die Werkzeug-Versionen und der freie Speicherplatz.
         </p>
+        {/* 25.07.2026 richtiggestellt: Updates bringen keine Disc-Schluessel mit — siehe UHD-Absatz unten. */}
         <p>
           <span className={fett}>Updates:</span> „Auf Updates prüfen" (ebenfalls Einstellungen →
           System) vergleicht die installierten Versionen mit makemkv.com und den offiziellen
           HandBrake-Releases. Gibt es ein MakeMKV-Update, zeigt Rippy den fertigen
-          Update-Befehl an — wichtig, weil neue Versionen auch die neueste
-          Disc-Schlüssel-Datenbank mitbringen.
+          Update-Befehl an — neue Versionen bringen bessere Laufwerks-Unterstützung und
+          Fehlerbehebungen. <span className={fett}>Disc-Schlüssel für 4K-UHD kommen dagegen nicht
+          aus einem Update</span>, sondern nur aus der Datei <code>KEYDB.cfg</code>, die du selbst
+          unter Einstellungen → System hochlädst (mehr dazu unter „Häufige Fragen").
         </p>
       </Abschnitt>
 
@@ -157,11 +160,31 @@ export default function AnleitungPage() {
           <span className={fett}>„Diese Disc wurde bereits gerippt"?</span> Rippy erkennt Discs am
           Fingerabdruck. Nochmal rippen geht trotzdem — der Hinweis verhindert nur Versehen.
         </p>
+        {/*
+          25.07.2026 auf der Rippy-VM nachgemessen und komplett neu geschrieben:
+          Hier stand vorher, ein MakeMKV-Update mache die Disc rippbar. Das stimmt
+          nicht — MakeMKV versucht bei einer unbekannten UHD-Pressung gar nicht mehr,
+          online einen Schluessel zu holen, und die dokumentierten Schluessel-Server
+          (hkdata.fairuse.org, hkdata.crabdance.com) loesen weltweit nicht mehr auf.
+        */}
         <p>
           <span className={fett}>4K-UHD schlägt fehl mit „volume key is unknown"?</span> Das Laufwerk
-          liest die Disc (LibreDrive), aber MakeMKV kennt den Schlüssel dieser (zu neuen) Pressung
-          noch nicht. Den automatisch gespeicherten AACS-Dump im MakeMKV-Forum einreichen — mit einem
-          der nächsten Updates ist die Disc rippbar.
+          liest die Disc einwandfrei (LibreDrive) — MakeMKV fehlt nur der Schlüssel dieser Pressung.
+          Früher holte MakeMKV solche Schlüssel selbst aus dem Netz; dieser Kanal liefert heute nichts
+          mehr, und ein MakeMKV-Update ändert daran nichts.
+        </p>
+        <p>
+          Der einzige Weg, der heute funktioniert, ist eine Datei namens <code>KEYDB.cfg</code> —
+          eine Textliste mit Disc-Schlüsseln, die du selbst mitbringst. Unter Einstellungen → System
+          hochladen, sie wirkt ab dem nächsten Rip. <span className={fett}>Rippy liefert keine
+          Schlüssel mit und lädt auch keine herunter</span> — Rippy stellt nur den Platz für deine
+          Datei bereit und zeigt dir an, was dort liegt.
+        </p>
+        <p>
+          Der <span className={fett}>AACS-Dump</span> zu einer gescheiterten Disc bleibt jetzt
+          erhalten und steht unter Einstellungen → System zum Herunterladen. Ihn kannst du im
+          MakeMKV-Forum im Bereich „Ultra HD Blu-ray" einreichen — daraus lässt sich der Schlüssel
+          für deine Pressung ermitteln, den du dann in deine <code>KEYDB.cfg</code> einträgst.
         </p>
         <p>
           <span className={fett}>„Neu komprimieren" fehlt bei einem Fehl-Job?</span> Der Knopf