feat(installer): der Windows-Installer holt die Freigabe jetzt selbst von Rippy

DER BLOCKER aus dem SAVEPOINT v3.16 ist zu. Beide Installer (Kommandozeile und
GUI) fragen GET /worker-setup/pfad-map, pruefen mit Test-Path, ob DIESER PC die
Freigabe wirklich erreicht, und schreiben `set RIPPY_PATH_MAP=...` in
start-tray.bat und start-worker.bat.

Der Commander muss dafuer nichts ueber Container-Pfade wissen - das Feld bleibt
leer, der Installer holt den Wert. Von Hand geht es trotzdem (Knopf "Von Rippy
holen" bzw. -PfadMap), falls dieser PC die Freigabe anders erreicht.

Ist nichts erreichbar, steht das als Klartext im Log samt dem haeufigsten Grund
(fehlende Zugangsdaten - Freigabe einmal im Explorer oeffnen). Die Installation
laeuft weiter: ein Worker, der sich meldet und ehrlich scheitert, ist besser als
einer, der nicht existiert. Ein LEERES RIPPY_PATH_MAP wird bewusst nicht
gesetzt - pfad_lokal() liest das als "kein Mapping", und die Fehlermeldung im
Worker unterscheidet genau diese beiden Faelle.

GUI: neues Feld samt Knopf, Fenster 560->648 px. Layout headless gerendert und
angesehen (nichts ueberlappt, Umlaute korrekt), beide Dateien mit echtem
PowerShell 5.1 auf Parser-Fehler geprueft, UTF-8-BOM erhalten. .exe neu gebaut.
install.ps1 hatte durch ein Werkzeug LF statt CRLF bekommen - zurueckgedreht.

remote-transcode-worker.yml richtiggestellt: Dort stand "mount -t nfs
<rippy-host>:/srv/rippy" - das geht NICHT, auf der Rippy-Maschine laeuft kein
NFS- und kein Samba-Server, sie ist selbst nur Client der NAS. Der Weg, der
funktioniert: dieselbe Freigabe einhaengen, die auch Rippy nutzt.

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

deploy/remote-transcode-worker.yml

@@ -1,17 +1,36 @@
-# Optionaler Remote-Transcode-Worker — für eine GPU-Maschine im Netz.
-# (EXPERIMENTELL, 23.07.2026: VAAPI/NVENC-Presets folgen; aktuell nutzt der
-#  Worker dieselben HandBrake-CPU-Presets, bringt also v.a. stärkere CPUs.)
+# Optionaler Remote-Transcode-Worker — für eine GPU-Maschine im Netz (Linux).
+# Für Windows gibt es den nativen Weg: RippyWorkerSetup.exe (Einstellungen → Worker).
+#
+# ══ DAS ENTSCHEIDENDE: der Worker muss die Dateien SEHEN ══════════════════════
+# Rippy schickt ihm Pfade wie /app/media/rippy/<job>/title_t00.mkv — Pfade
+# INNERHALB des Rippy-Containers. Dieser Container muss dieselben Daten unter
+# GENAU DEMSELBEN Pfad haben, sonst nimmt er die Aufgabe an und lehnt sie
+# Millisekunden später ab („Keine Roh-MKVs gefunden" — genau so passiert am
+# 26.07.2026, Job 95afdc89).
+#
+# Richtigstellung 26.07.2026: Hier stand vorher „mount -t nfs
+# <rippy-host>:/srv/rippy /mnt/rippy". Das geht NICHT — auf der Rippy-Maschine
+# läuft kein NFS- und kein Samba-Server, sie ist selbst nur Client der NAS.
+# Der Weg, der funktioniert: DIESELBE Freigabe einhängen, die auch Rippy nutzt.
 #
 # Auf der GPU-Maschine:
 #   1. Dieses Repo klonen (oder nur dieses File + Zugriff aufs Registry-Image)
-#   2. Rohdaten-Freigabe der Rippy-Maschine mounten, z. B.:
-#      mount -t nfs <rippy-host>:/srv/rippy /mnt/rippy
-#      (die Rippy-VM muss /srv/rippy + das temp-Volume exportieren)
-#   3. RIPPY_HOST unten setzen und starten:
-#      docker compose -f deploy/remote-transcode-worker.yml up -d --build
+#   2. Die Freigabe einhängen, die Rippy als Arbeitsverzeichnis UND Ablage
+#      benutzt (Einstellungen → Ripping). Heißt sie in Rippy „rippy", liegt
+#      sie dort unter /app/media/rippy — also z. B.:
+#        mount -t cifs //NAS/rippy /mnt/rippy-freigabe -o guest,iocharset=utf8
+#   3. Unten RIPPY_HOST setzen, den Freigabe-Pfad im volumes-Block anpassen
+#      und starten:
+#        RIPPY_HOST=192.168.178.162 docker compose \
+#          -f deploy/remote-transcode-worker.yml up -d --build
+#
+# Passt der Pfad im Container nicht (weil die Freigabe woanders hängt), gibt es
+# als Ausweg RIPPY_PATH_MAP — dieselbe Übersetzung, die der Windows-Worker
+# nutzt, Format: /app/media/rippy=/mnt/anderer-pfad (Paare per „;").
+# Den fertigen Wert nennt GET /worker-setup/pfad-map.
 #
 # Der Worker meldet seine Encoder-Fähigkeiten automatisch — er taucht danach
-# unter Einstellungen → Verarbeitung auf. Er bedient NUR die transcode-Queue;
+# unter Einstellungen → Worker auf. Er bedient NUR die transcode-Queue;
 # gerippt wird weiterhin dort, wo das Laufwerk hängt.
 
 services:
@@ -30,10 +49,15 @@ services:
       - WORKER_NAME=${WORKER_NAME:-transcode-worker}
       # Serien-Episoden-Matching fragt die Rippy-API nach Laufzeiten
       - API_URL=http://${RIPPY_HOST}:8000
+      # Nur nötig, wenn die Freigabe hier NICHT unter demselben Pfad liegt wie
+      # in Rippy. Fertigen Wert holen: curl http://${RIPPY_HOST}/api/worker-setup/pfad-map
+      - RIPPY_PATH_MAP=${RIPPY_PATH_MAP:-}
     volumes:
-      # Freigabe der Rippy-Maschine (siehe Kopf-Kommentar)
-      - /mnt/rippy/media:/app/media
-      - /mnt/rippy/temp:/app/temp
+      # LINKS der Pfad auf DIESER Maschine, RECHTS der Pfad, den Rippy nennt.
+      # Rechts muss stehen, was in Rippy als Speicherziel heißt: ein Ziel
+      # namens „rippy" ist dort /app/media/rippy. Prüfen mit
+      #   curl http://<rippy-host>/api/worker-setup/pfad-map
+      - /mnt/rippy-freigabe:/app/media/rippy
     devices:
       # GPU für Hardware-Encoding (AMD/Intel: /dev/dri; NVIDIA: nvidia-runtime)
       - /dev/dri:/dev/dri