feat(windows): Rippy arbeitet eigenstaendig — Rippen, Werkzeuge, Fähigkeiten

WAS: Der Ablauf ist aus tasks.py heraus (ablauf.py, ohne Celery), die
LocalQueue wird bedient, ein Laeufer arbeitet Auftraege im selben Prozess
ab, und Rippy meldet sich mit gemessenen Faehigkeiten selbst als Arbeiter.

WARUM: "Rippy fuer Windows soll standalone funktionieren" (Commander). Bis
hierher konnte die Windows-App alles ANZEIGEN und nichts TUN — ein Rip waere
eingereiht worden und fuer immer liegengeblieben, weil niemand ihn holt.

DIE TRENNUNG: rip_disc hing an GENAU DREI Celery-Stellen in 234 Zeilen —
self.update_state, _transcode_queue, transcode_files.apply_async. Alle drei
sind Fragen der ZUSTELLUNG, nicht des Ablaufs. Sie sind jetzt Rueckrufe:
tasks.py reicht die Celery-Fassung herein, standalone.py die lokale. OHNE
Rueckruf komprimiert derselbe Prozess weiter — genau das, was ein
Ein-Prozess-Rippy braucht. Der Ablauf selbst ist Zeile fuer Zeile derselbe;
der Docker-Betrieb merkt vom Umbau nichts (Task-Namen, Argumente, Queues
unveraendert).

EINE ZUSTELL-STELLE statt drei: celery_client.abschicken() bedient alle
Auftragsarten. Vorher rief jede Stelle send_task selbst auf — der
Standalone-Betrieb haette an drei Stellen umgebogen werden muessen, beim
naechsten Auftragstyp an einer vierten.

WEITERER BLOCKER GEFUNDEN: ablauf.py holte detect_disc_type fest aus dem
LINUX-Treiber, in einem try/except. Unter Windows waere es damit IMMER None
gewesen und Rippen "hart verriegelt" — Rippy haette alles angezeigt und
nichts gerippt, ohne dass irgendwo ein Fehler stuende. Jetzt fragt es den
Treiber-Port.

WERKZEUGE: ripping.py und caps.py suchten nur im PATH. Auf dem Commander-PC
gemessen, vorher/nachher:

  vorher   check_makemkv_installed()  -> False (obwohl installiert)
           erkenne_encoder()          -> nur CPU
  nachher  MakeMKV   1.18.4  C:\Program Files (x86)\MakeMKV\makemkvcon64.exe
           HandBrake 1.11.2  ueber die API geholt, in 2,7 s
           Encoder   cpu-x264, cpu-x265, cpu-av1, VCE, VCE-AV1
           107 Presets, Ryzen 7 9700X, 16 Kerne, avx512f

VCE ist die Hardwarebeschleunigung der Radeon — die hat Rippy auf diesem
Rechner vorher nie gesehen, weil es HandBrake gar nicht fand.

NEUE ROUTEN: GET /system/werkzeuge (was liegt wo, in welcher Fassung, gibt
es Neueres) und POST /system/werkzeuge/{name}/holen. HandBrake kommt
vollautomatisch von GitHub. MakeMKV wird NICHT mitgeliefert — Rippy laedt
die offizielle Datei und startet sie (Black-Box-Trennung, KONZEPT.md § 6).
makemkv.com antwortete beim Bauen mit HTTP 525; das wird im Klartext
gemeldet, und eine selbst geholte Datei bleibt moeglich.

HERZSCHLAG: /capabilities las die workers-Tabelle, die bisher nur der
Celery-Herzschlag fuellte. Im Standalone-Betrieb stand dort "0 Worker" und
die Encoder-Auswahl im UI blieb LEER — auf einem Rechner, der alles kann.
Jetzt meldet sich der Prozess selbst, mit dem, was caps.py MISST.

GEMESSEN, aus der fertigen EXE (29,0 MB):
  bereit nach 1 s, keine Fehler im Log
  Werkzeuge: beide gefunden, mit Version und Pfad
  Worker: 1 (TobisNicerPC), 5 Encoder, 107 Presets

Die ganze Kette ist als Test festgehalten (test_kette.py): zustellen ->
einreihen -> Laeufer -> ablauf -> Job endet in einem EHRLICHEN Zustand.
Ohne Laufwerk geprueft, und das ist der wichtigere Fall: Ein Rip auf ein
totes Geraet muss zuegig scheitern, nicht auf "pending" haengenbleiben.

GEMESSEN: ruff sauber, 512 Tests gruen + 15 uebersprungen (vorher 489).

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

docker/worker/test_erreichbarkeit.py

@@ -7,7 +7,7 @@ erreicht das Ziel nicht", obwohl die Freigabe erreichbar war. Es fehlten nur
 zwei noch nie angelegte Ordner.
 """
 
-import tasks
+import ablauf as tasks
 
 
 # --- Der eigentliche Fehler: nur EINE fehlende Ebene war erlaubt -------------

docker/worker/test_medien.py

@@ -105,7 +105,7 @@ def test_matche_episoden_ohne_treffer_gibt_none():
 
 
 def test_pfad_lokal_uebersetzt_fuer_windows_worker():
-    from tasks import pfad_lokal
+    from ablauf import pfad_lokal
 
     mapping = "/app/media=Z:\\media;/app/temp=Y:\\temp"
     assert pfad_lokal("/app/temp/raw/abc", mapping) == "Y:\\temp\\raw\\abc"
@@ -128,7 +128,7 @@ def test_arbeitsverzeichnis_wahl_des_rips_schlaegt_die_einstellung():
     Setting-Wert ist genau der, der bei Vollautomatik-Rips greift, weil dort
     niemand gefragt wird.
     """
-    import tasks
+    import ablauf as tasks
 
     einst = {"workDir": "/app/media/movies"}
     assert tasks._arbeitsverzeichnis(einst, "/app/media/rippy") == "/app/media/rippy"
@@ -144,7 +144,7 @@ def test_arbeitsverzeichnis_wahl_des_rips_schlaegt_die_einstellung():
 def test_unter_wurzel_faellt_nicht_auf_praefix_namen_herein():
     """Befund 25.07.2026: Elf Stellen prüften mit nacktem startswith().
     „/app/media-boese/x" beginnt mit „/app/media", liegt aber außerhalb."""
-    import tasks
+    import ablauf as tasks
 
     assert tasks.unter_wurzel("/app/media", "/app/media") is True
     assert tasks.unter_wurzel("/app/media/movies", "/app/media") is True
@@ -160,7 +160,7 @@ def test_unter_wurzel_faellt_nicht_auf_praefix_namen_herein():
 
 
 def test_zielbasis_lehnt_praefix_ausbruch_ab():
-    import tasks
+    import ablauf as tasks
 
     assert tasks._zielbasis("/app/media/movies", "bluray") == "/app/media/movies"
     # Ausbruch per Praefix-Namen fällt auf den Standard zurück
@@ -169,7 +169,7 @@ def test_zielbasis_lehnt_praefix_ausbruch_ab():
 
 
 def test_arbeitsverzeichnis_lehnt_praefix_ausbruch_ab():
-    import tasks
+    import ablauf as tasks
 
     assert tasks._arbeitsverzeichnis({}, "/app/media-boese") == tasks.RAW_DIR
     assert tasks._arbeitsverzeichnis({"workDir": "/app/mediaX"}) == tasks.RAW_DIR

docker/worker/test_original_aufheben.py

@@ -13,7 +13,7 @@ import os
 
 import pytest
 
-import tasks
+import ablauf as tasks
 
 
 class FakeDb:

docker/worker/test_ripping_helpers.py

@@ -40,7 +40,11 @@ def test_handbrake_cmd_arbeitet_auf_datei_nicht_geraet():
     MakeMKV-Rip, nie das Laufwerk (die alte Direkt-am-Gerät-Pipeline war
     für Blu-rays prinzipiell funktionsunfähig)."""
     cmd = build_handbrake_cmd("/app/temp/raw/x/t00.mkv", "/app/media/bluray/x/t00.mkv")
-    assert cmd[0] == "HandBrakeCLI"
+    # Wie beim MakeMKV-Befehl: seit V2-4 steht hier der GEFUNDENE Pfad. Unter
+    # Windows liegt HandBrakeCLI in Program Files oder in Rippys eigenem
+    # Werkzeug-Ordner und nicht im PATH — mit dem nackten Namen faende
+    # `subprocess` es dort nie.
+    assert "handbrakecli" in cmd[0].lower()
     assert cmd[cmd.index("--input") + 1] == "/app/temp/raw/x/t00.mkv"
     assert cmd[cmd.index("--output") + 1] == "/app/media/bluray/x/t00.mkv"
     assert "--preset" in cmd

docker/worker/test_zombies.py

@@ -221,7 +221,11 @@ def test_arbeitsstati_deckt_ab_was_der_worker_wirklich_schreibt():
     import os
     import re
 
-    pfad = os.path.join(os.path.dirname(os.path.abspath(__file__)), "tasks.py")
+    # Seit V2-4 steht der Ablauf in ablauf.py; tasks.py ist nur noch
+    # die Celery-Huelle. Dieser Waechter muss dorthin schauen, wo der
+    # Code WIRKLICH steht — sonst prueft er eine leere Datei und ist
+    # gruen, ohne etwas zu beweisen.
+    pfad = os.path.join(os.path.dirname(os.path.abspath(__file__)), "ablauf.py")
     quelle = open(pfad, encoding="utf-8").read()
 
     # Nur die Aufrufe, die wirklich die Job-Zeile aendern.