feat(ui): Presets vom Worker, Warnung vor unerreichbaren Pfaden, Browser weg

Vier Commander-Punkte auf einmal, alle am selben Ort.

Presets (Punkt 1 + 3b): Die drei Auswahllisten in Einstellungen kommen jetzt
vom Worker statt aus dieser Datei, gefiltert auf die passende Aufloesung - die
4K-Liste bietet keine 1080p-Presets mehr als Normalfall an (genau dieser Griff
rechnete in v3.12 eine 4K-UHD auf 1080p herunter; bewusstes Verkleinern steht
jetzt in einer eigenen, benannten Gruppe). Knopf "Bestes waehlen" uebernimmt die
Empfehlung fuer alle drei Disc-Typen, und unter jeder Liste steht, WARUM. Ein
gespeicherter Wert, den der Worker nicht kennt, wird benannt statt verschluckt -
so faellt eine falsche Bestandseinstellung ueberhaupt auf.
Der Wizard entscheidet nicht mehr selbst, sondern nimmt dieselbe Empfehlung.
Damit gibt es nur noch EINE Stelle mit dieser Logik, und die hat Tests.

Warnung vor dem Start (Punkt 6 des Savepoints): Waehlt man einen externen
Encoder, der Quelle oder Ziel nicht erreicht, steht das JETZT im Rip-Dialog -
nicht erst nach einer Stunde Rip. Geprueft wird mit derselben Regel, die
pfad_lokal() im Worker anwendet. Bei "Automatisch" wird genannt, welcher Worker
die Aufgabe kaputtmachen koennte: die geteilte Queue nimmt den ersten freien.

Datei-Browser (Punkt 7): "Warum wird hier der Datei Browser noch angezeigt - das
ist doch quatsch." Er ist nicht wirklich redundant (nur ueber ihn geht ein
freier Zielordner fuer EINEN Rip), aber er ueberschrieb die Schnellwahl
stillschweigend. Jetzt eingeklappt - wer ihn aufklappt, entscheidet bewusst, und
/browse wird erst dann geholt. Nebenbefund: browseFiles wurde geladen und NIE
angezeigt, samt ungenutztem File-Icon - beides raus.

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

docker/ui/src/lib/encoder.ts

@@ -33,6 +33,91 @@ interface WorkerFuerBewertung {
   info?: { cpu_simd?: string }
 }
 
+// --- Erreicht ein EXTERNER Worker die Pfade? ---------------------------------
+//
+// Befund 26.07.2026, live am Job 95afdc89: Das Routing an den Windows-PC des
+// Commanders funktionierte einwandfrei — der Worker nahm die Aufgabe an und
+// lehnte sie 182 ms später ab, weil `/app/media/...` Pfade INNERHALB des
+// Rippy-Containers sind. Ohne RIPPY_PATH_MAP sieht ein externer Worker sie nie.
+// Auffallen durfte das nicht erst nach einer Stunde Rip, sondern hier.
+
+interface WorkerFuerPfadPruefung {
+  name: string
+  node?: string | null
+  info?: { extern?: string, pfad_map?: string }
+}
+
+/**
+ * Deckt `RIPPY_PATH_MAP` diesen Container-Pfad ab? Gleiche Regel wie
+ * `pfad_lokal()` im Worker (docker/worker/tasks.py): Paare `quelle=ziel`,
+ * getrennt durch `;`, Treffer per Präfix.
+ */
+export function pfadAbgedeckt(pfad: string, mapping: string): boolean {
+  if (!pfad || !mapping) return false
+  return mapping.split(';').some(paar => {
+    const quelle = paar.split('=', 1)[0]
+    return !!quelle && pfad.startsWith(quelle)
+  })
+}
+
+/**
+ * Warnt, BEVOR gerippt wird, wenn der gewählte Encoder die Pfade nicht
+ * erreichen kann. null = alles in Ordnung (oder der Worker läuft im Container,
+ * dann gibt es nichts zu übersetzen).
+ *
+ * `arbeitsPfad` leer heißt: Container-Standard /app/temp/raw — ein Docker-Volume,
+ * an das ein externer Worker grundsätzlich nicht herankommt.
+ */
+export function externWarnung(
+  worker: WorkerFuerPfadPruefung | undefined,
+  zielPfad: string,
+  arbeitsPfad: string,
+): string | null {
+  if (!worker || worker.info?.extern !== 'ja') return null
+  const mapping = (worker.info?.pfad_map || '').trim()
+  if (!mapping) {
+    return `„${worker.name}" läuft auf einer anderen Maschine und hat keine `
+      + 'Pfad-Übersetzung (RIPPY_PATH_MAP). Er kann die Rohdaten deshalb nicht '
+      + 'finden und würde sofort abbrechen. Abhilfe: den Windows-Installer erneut '
+      + 'ausführen — er holt den Wert jetzt selbst von Rippy. Bis dahin besser '
+      + '„Automatisch" wählen.'
+  }
+  if (!arbeitsPfad) {
+    return `„${worker.name}" arbeitet auf einer anderen Maschine. Das `
+      + 'Arbeitsverzeichnis steht auf der Container-Platte (/app/temp) — die ist '
+      + 'von außen nicht erreichbar. Oben eine Netzwerk-Freigabe als '
+      + 'Arbeitsverzeichnis wählen.'
+  }
+  const fehlt: string[] = []
+  if (!pfadAbgedeckt(arbeitsPfad, mapping)) fehlt.push(`Rohdaten (${arbeitsPfad})`)
+  if (!pfadAbgedeckt(zielPfad, mapping)) fehlt.push(`Ziel (${zielPfad})`)
+  if (fehlt.length === 0) return null
+  return `„${worker.name}" erreicht ${fehlt.join(' und ')} nicht — seine `
+    + `Übersetzung deckt nur „${mapping}" ab. Beides muss auf einer Freigabe `
+    + 'liegen, die diese Maschine sieht, sonst scheitert die Kompression '
+    + '(die Rohdaten bleiben dabei erhalten).'
+}
+
+/**
+ * Dasselbe Risiko bei „Automatisch": dort nimmt die geteilte Queue den ersten
+ * freien Worker — auch einen externen, der die Pfade nicht erreicht. Nennt die
+ * betroffenen Namen, damit man gezielt einen anderen wählt.
+ */
+export function automatikWarnung(
+  workers: WorkerFuerPfadPruefung[] | undefined,
+  zielPfad: string,
+  arbeitsPfad: string,
+): string | null {
+  const betroffen = (workers || [])
+    .filter(w => externWarnung(w, zielPfad, arbeitsPfad) !== null)
+    .map(w => w.name)
+  if (betroffen.length === 0) return null
+  return `Bei „Automatisch" nimmt die Aufgabe der erste freie Worker — das kann `
+    + `${betroffen.join(', ')} sein, und dort scheitert sie an den Pfaden. `
+    + 'Wähle oben gezielt eine Maschine, die die Freigabe erreicht — oder rüste '
+    + 'die Pfad-Übersetzung nach (Windows-Installer erneut ausführen).'
+}
+
 /**
  * Kann von den gemeldeten Workern KEINER 4K in Software brauchbar schnell
  * encodieren? Wahr nur, wenn das auch belegt ist: mindestens ein Worker hat