feat(schluessel): der Windows-PC holt die 4K-Schluessel jetzt selbst

Auf Commander-Entscheid gebaut. Belegt am 25.07.2026 auf beiden Maschinen:
`makemkvcon` unter LINUX ruft Disc-Schluessel NIE ab, die WINDOWS-Version schon
(Meldung 3338). Deshalb scheiterte jede unbekannte UHD-Disc auf der VM mit "The
volume key is unknown", und der Weg, der funktioniert, war Handarbeit: Laufwerk
an den PC, Disc oeffnen, _private_data.tar suchen, im UI hochladen.

Das laeuft jetzt von selbst - und zwar ZWEISCHICHTIG, mit Absicht:

  1. Der WAECHTER (verlaesslich): sieht _private_data.tar nach und laedt sie zu
     Rippy hoch, sobald sie sich geaendert hat. Braucht keine
     Laufwerkserkennung, kein Disc-Oeffnen, nichts geraten. Deckt auch den Fall
     ab, dass man die Disc einfach in der MakeMKV-Oberflaeche oeffnet.
  2. Das ANSTOSSEN (nach bestem Wissen): liegt eine Disc im Laufwerk, wird
     `makemkvcon info` darauf losgelassen - dabei holt MakeMKV den Schluessel.

Warum getrennt: Das Format der BELEGTEN `DRV:`-Zeile liess sich auf dem
Commander-PC nicht messen, weil dort kein optisches Laufwerk steckt (alle 16
Plaetze melden `DRV:i,256,999,0,"","",""` - das ist gemessen). Geraten wird also
nur in Schicht 2, und wenn die Vermutung falsch ist, passiert dort einfach
nichts - Schicht 1 arbeitet weiter. Die teure Annahme steckt nie im
verlaesslichen Teil.

Gemessene Fundstellen: Datenverzeichnis ist `%USERPROFILE%\.MakeMKV` (NICHT
%APPDATA%\MakeMKV, wie man vermuten wuerde) - dort lag die echte Datei mit
6.420.480 Bytes. Programm: C:\Program Files (x86)\MakeMKV\makemkvcon64.exe,
v1.18.4. Hochgeladen wird mit ROHEM Koerper an POST /system/keystore, weil der
API python-multipart fehlt.

Die Automatik schaltet sich selbst ab, wenn MakeMKV nicht installiert ist: Auf
einem reinen Encoding-PC gibt es nichts zu holen, und eine Schleife, die jede
Minute ins Leere greift, waere nur Rauschen. Ihre Meldungen gehen ueber die
Log-Bruecke auch nach Rippy - das ist genau die Auskunft, auf die man nach dem
Einlegen einer neuen UHD-Disc wartet.

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

docker/worker/tray.py

@@ -254,6 +254,37 @@ def _job_holen():
     return None
 
 
+def _schluessel_wache(bruecke=None):
+    """Holt 4K-Disc-Schlüssel und schiebt sie zu Rippy (siehe schluessel.py).
+
+    Der Sinn in einem Satz: `makemkvcon` unter LINUX ruft Disc-Schlüssel nie ab,
+    die WINDOWS-Version schon — und dieser Worker läuft auf Windows. Damit fällt
+    die Handarbeit weg, `_private_data.tar` nach jeder neuen UHD-Disc selbst
+    hinüberzutragen.
+
+    Schaltet sich selbst ab, wenn MakeMKV hier nicht installiert ist: Auf einem
+    reinen Encoding-PC gibt es nichts zu holen, und eine Schleife, die jede
+    Minute ins Leere greift, wäre nur Rauschen.
+    """
+    import schluessel
+
+    if not schluessel.makemkvcon_pfad():
+        return
+
+    def melden(level, text):
+        if bruecke:
+            bruecke.zeile(f"[schluessel] {level.upper()} {text}")
+        print(f"Schlüssel-Automatik: {text}")
+
+    stand = None
+    while True:
+        try:
+            stand, _was = schluessel.runde(RIPPY_HOST, stand, melden=melden)
+        except Exception as e:  # darf den Worker nie mitnehmen
+            print(f"Schlüssel-Automatik fehlgeschlagen: {type(e).__name__}: {e}")
+        time.sleep(schluessel.TAKT_SEKUNDEN)
+
+
 def _beobachter(icon):
     """Fragt im Takt nach, was läuft — für Menütext und Standby-Sperre."""
     while True:
@@ -377,6 +408,13 @@ if __name__ == "__main__":
     threading.Thread(
         target=_beobachter, args=(tray,), daemon=True, name="job-beobachter"
     ).start()
+    # Schlüssel-Automatik für 4K-UHD. Eigene Log-Brücke, damit ihre Meldungen
+    # auch in Rippy landen ("Schlüsselspeicher übergeben") — das ist genau die
+    # Auskunft, auf die man nach dem Einlegen einer neuen UHD-Disc wartet.
+    threading.Thread(
+        target=_schluessel_wache, args=(_bruecke_bauen(),),
+        daemon=True, name="schluessel-wache",
+    ).start()
     try:
         tray.run()
     finally: