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/ui/src/pages/Anleitung.tsx

@@ -141,8 +141,8 @@ export default function AnleitungPage() {
           HandBrake-Releases. Gibt es ein MakeMKV-Update, zeigt Rippy den fertigen
           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").
+          aus einem Update</span> — die holt MakeMKV zur Laufzeit, und die Linux-Version tut das
+          nie. Wie du sie trotzdem bekommst, steht unter „Häufige Fragen".
         </p>
       </Abschnitt>
 
@@ -161,30 +161,34 @@ export default function AnleitungPage() {
           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.
+          25.07.2026 auf BEIDEN Maschinen nachgemessen und erneut korrigiert. Es
+          stand hier nacheinander zweierlei Falsches: erst "ein MakeMKV-Update macht
+          die Disc rippbar", dann "MakeMKVs Schluessel-Kanal ist tot". Richtig ist:
+          makemkvcon unter Linux ruft die Schluessel nie ab, die Windows-Version
+          schon (Meldung 3338, Verbindung nach 185.84.108.20:443).
         */}
         <p>
           <span className={fett}>4K-UHD schlägt fehl mit „volume key is unknown"?</span> Das Laufwerk
           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.
+          Der Grund liegt nicht bei dir und nicht bei Rippy: <span className={fett}>die Linux-Version
+          von MakeMKV holt Disc-Schlüssel nie selbst aus dem Netz</span>. Die Windows-Version tut es.
+          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.
+          <span className={fett}>Der Weg drumherum:</span> MakeMKV einmalig auf einem Windows-PC
+          installieren (gleicher Beta-Key), das Laufwerk dort anstecken, die Disc öffnen — MakeMKV
+          lädt die Schlüssel dabei nach. Dann in MakeMKV unter <em>Preferences → General</em> das
+          „MakeMKV data directory" nachschlagen und die Datei <code>_private_data.tar</code> daraus
+          bei Rippy unter Einstellungen → System hochladen. Wirkt ab dem nächsten Rip. Für neue
+          Discs gelegentlich wiederholen — der Block dort zeigt dir, wie viele Schlüssel Rippy kennt.
         </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.
+          Geht eine Pressung auch damit nicht auf, kennt MakeMKV sie selbst nicht. Dann bleiben zwei
+          Dinge: eine <code>KEYDB.cfg</code> (ebenfalls dort hochladbar, der Notnagel), oder den
+          <span className={fett}> AACS-Dump</span> im MakeMKV-Forum im Bereich „Ultra HD Blu-ray"
+          einreichen — der bleibt jetzt erhalten und steht unter Einstellungen → System zum
+          Herunterladen. <span className={fett}>Rippy liefert keine Schlüssel mit und lädt keine
+          herunter</span> — es verwaltet nur, was du selbst mitbringst.
         </p>
         <p>
           <span className={fett}>„Neu komprimieren" fehlt bei einem Fehl-Job?</span> Der Knopf