Drei Praxis-Bugs: tote NAS-Mounts reparierbar, HandBrake-Versionen konsistent, Encoder-Wahl beim Rip

1) Speicher-Mounts robust (Befund: toter CIFS-Mount nach NAS-Ausfall/Rebuild —
   mounted:false, verschwand aus 'Verfuegbare Ziele', Neu-Anlegen -> 409, man
   sass fest):
   - mounts.py: ist_erreichbar() (listdir, soft-Mount bricht schnell ab),
     ist_gemountet() faengt OSError toter Mounts, aushaengen() mit
     umount -l Fallback, reparieren() (lazy abhaengen + frisch mounten).
   - /storage-mounts liefert 'reachable'; POST bei existierendem Namen:
     aktiv -> 409, tot -> automatische Reparatur mit neuen Angaben;
     neuer POST /storage-mounts/{name}/repair (gespeicherte Zugangsdaten).
   - /storage-targets crasht nicht mehr an totem Mount (os.path.ismount
     OSError abgefangen).
   - UI: eigene 'Netzwerk-Mounts'-Liste mit Status (aktiv/nicht erreichbar/
     getrennt) + Reparieren- und Entfernen-Knopf — tote Mounts sind sichtbar
     und wiederherstellbar statt zu verschwinden.

2) HandBrake-Versionen konsistent (Befund: Docker 1.6.1, Windows-Skript
   fest 1.9.2, Update-Check meldet 1.11.2 — verwirrend):
   - Windows-Installer zieht jetzt DYNAMISCH die neueste Version (GitHub
     latest, Fallback 1.11.2) — passt zum Update-Check.
   - Update-UI erklaert klar: Docker = stabiles Debian-Paket (bewusst aelter,
     kein Fehler), Windows = neueste. MakeMKV-Update zeigt den Befehl.

3) Encoder-/Worker-Auswahl beim Rip (Feature):
   - Celery worker_direct=True: jeder Worker konsumiert zusaetzlich seine
     Direkt-Queue. API-Helper transcode_queue(node) routet gezielt an den
     gewaehlten Worker, faellt aber sicher auf die geteilte transcode-Queue
     zurueck, wenn er offline ist (kein Haengenbleiben).
   - /capabilities liefert den Celery-Node je Worker; POST /jobs nimmt
     transcode_node (-> Job-meta); rip_disc + retry-transcode routen danach.
   - Rip-Dialog: Encoder-/Worker-Dropdown, sichtbar ab 2 Online-Workern.
   - ping_worker-Task zum Verifizieren des gezielten Routings.
   - Nebenfund gefixt: DeviceDiscovery leitete die Titel-Auswahl (titles)
     gar nicht an die API weiter — jetzt titles + transcode_node.

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

docker/api/celery_client.py

@@ -7,12 +7,33 @@ kein POST /jobs, kein udev-Daemon. Dieser Client schließt die Lücke.
 import os
 
 from celery import Celery
+from celery.utils import worker_direct
 
 REDIS_URL = os.getenv("REDIS_URL", "redis://localhost:6379/0")
 
 celery_client = Celery("rippy_api", broker=REDIS_URL, backend=REDIS_URL)
 
 
+def transcode_queue(node: str = None):
+    """Ziel-Queue für die Kompression: der GEWÄHLTE Worker (worker_direct)
+    wenn er gerade online ist, sonst die geteilte transcode-Queue.
+
+    So kann ein Job gezielt einen Encoder ansprechen — fällt der Worker aber
+    weg, bleibt die Kompression nicht in einer toten Queue hängen, sondern
+    landet bei irgendeinem freien Worker.
+    """
+    if not node:
+        return "transcode"
+    try:
+        antworten = celery_client.control.ping(timeout=1.0) or []
+        online = {k for antwort in antworten for k in antwort.keys()}
+        if node in online:
+            return worker_direct(node)
+    except Exception:
+        pass
+    return "transcode"
+
+
 def start_rip(device_path: str, job_id: str, target_dir: str = None):
     """Schickt den Rip-Task an den Worker (Task-Name aus worker/tasks.py)."""
     return celery_client.send_task(