Windows-Worker: Pfad-Mapping fuer echte Transcodes + leere-Titel-Meldung + E2E-Beweis dokumentiert

- pfad_lokal (tasks.py, mit Tests): RIPPY_PATH_MAP uebersetzt
  Container-Pfade (/app/temp, /app/media) auf Netzlaufwerke des nativen
  Workers — ohne Mapping unveraendert (Docker-Worker).
- Rip-Dialog: 'done' mit 0 Titeln bekommt Klartext (Disc vermutlich
  nicht entschluesselbar) statt leerer Tabelle.
- SAVEPOINT: E2E-Beweis des nativen Windows-Workers dokumentiert
  (test-windows-nativ online, HandBrake 1.9.2, echte LAN-IP).

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

SAVEPOINT.md

@@ -17,8 +17,15 @@
   GitHub-Release (URL verifiziert), start-worker.bat (celery -Q transcode
   --pool=solo), optional -Autostart (schtasks onlogon). tasks.py lädt auf
   Windows ohne fcntl (Import-Guard); rip_disc ist dort hart verriegelt.
-  **E2E-BEWEIS: von diesem Windows-PC aus installiert, verbunden und ein
-  echter Transcode-Job gegen die VM gefahren** (Ergebnis siehe unten).
+  Für echte Transcodes übersetzt RIPPY_PATH_MAP die Container-Pfade aufs
+  Netzlaufwerk (pfad_lokal, mit Tests) — Voraussetzung bleibt eine
+  Freigabe der Rippy-Ablage (derselbe offene Infra-Punkt wie beim
+  Linux-Remote-Worker/AI-Box).
+  **E2E-BEWEIS (24.07., Commander-PC):** Installer in einem Rutsch
+  durchgelaufen (venv, Abhängigkeiten, HandBrakeCLI 1.9.2), Worker
+  gestartet und in Rippy erschienen:
+  `test-windows-nativ | online: True | HandBrake: 1.9.2 | IP: 192.168.178.98`
+  — echte LAN-IP, Celery-Ping grün. Testeintrag danach wieder entfernt.
 - **Anleitungs-Tab** im UI: kompletter Selbsterklärer (Disc-Weg, Serien,
   NAS, Media-Server, Benachrichtigungen, Key, Worker, Downloads, FAQ).
 - Design 2.0 kommt bewusst in eine FRISCHE Session (Commander-Entscheid) —