fix(ui): die Ablage war im UI ueberhaupt nicht einstellbar

Der Grund, warum der erste Rip mit externem Encoder scheitern MUSSTE - und
Commander-Vorgabe: "Wenn ein externes Ziel eingehaengt ist, soll Rippy das
ausgewaehlte als Arbeitsziel verwenden. Das stellt man ja sowieso in den
Einstellungen ein. Das muss auch fuer den Automatik-Modus so sein."

Genau das ging nicht. outputDir stand in den Einstellungen, wurde von der
Vollautomatik (main.py) und der Schnellwahl (RipTargetModal) gelesen - aber es
gab NIRGENDS ein Eingabefeld. Die Ablage klebte auf /app/media, der
Container-Platte. Das Arbeitsverzeichnis hatte eine Auswahlliste der
eingehaengten Ziele, das Ziel nicht.

Folge im Praxistest: Rohdaten auf der NAS (die der PC erreicht), Ziel auf der
VM-Platte (die er nicht erreicht, kein Samba dort). Der externe Encoder konnte
lesen, aber nicht schreiben - und das haette man mit den vorhandenen
Bedienelementen gar nicht anders einstellen koennen.

JETZT: Ablage-Auswahl in Einstellungen -> Ripping, mit derselben Liste
eingehaengter Ziele wie das Arbeitsverzeichnis. Damit wirkt sie automatisch
auch in der Vollautomatik und in der Schnellwahl, weil beide outputDir lesen -
also genau so, wie der Commander es beschrieben hat.

DAZU die Pruefung, die den Vorfall verhindert haette: Sobald ein EXTERNER
Worker gemeldet ist, warnt das UI, wenn Ablage und Arbeitsverzeichnis nicht
beide auf einer erreichbaren Freigabe liegen. Drei Faelle, jeweils mit der
Konsequenz im Klartext:
  - Arbeitsverzeichnis auf der Container-Platte -> externer Encoder kann nicht lesen
  - Arbeit auf Freigabe, Ablage lokal -> kann lesen, nicht schreiben (der Vorfall)
  - beide auf VERSCHIEDENEN Freigaben -> laeuft, kostet aber eine Vollkopie

"Extern" ist dabei keine Heuristik ueber IPs oder Namen: caps.py meldet es
selbst (`extern`), weil /app im Rippy-Image immer existiert und ausserhalb nie.
Zusaetzlich meldet der Worker jetzt seine `pfad_map` - damit kann das UI im
naechsten Schritt sagen, ob die Uebersetzung ueberhaupt gesetzt ist.

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

docker/worker/caps.py

@@ -269,6 +269,16 @@ def werkzeug_versionen() -> dict:
         "cpu_modell": modell,
         "cpu_kerne": str(kerne),
         "cpu_simd": simd,
+        # Läuft dieser Worker INNERHALB des Rippy-Containers oder auf einer
+        # fremden Maschine? Entscheidend, weil ein externer Worker die
+        # Container-Pfade (/app/media, /app/temp) nur über eine Freigabe plus
+        # RIPPY_PATH_MAP erreicht. Das UI kann damit VOR dem Rip warnen, statt
+        # den Nutzer eine Stunde rippen zu lassen (Vorfall 25.07.2026).
+        # /app ist im Rippy-Image immer vorhanden — kein Ratespiel.
+        "extern": "nein" if os.path.isdir("/app") else "ja",
+        # Ist die Pfad-Übersetzung gesetzt? Ohne sie kann ein externer Worker
+        # grundsätzlich nicht komprimieren.
+        "pfad_map": os.getenv("RIPPY_PATH_MAP", ""),
     }
     hb_encoder = parse_encoder_liste(hole_handbrake_hilfe())
     if hb_encoder: