fix(caps,ui): Encoder werden gemessen statt behauptet

Der Modulkopf von caps.py verspricht "ehrlich erkannt, nicht behauptet" -
erkenne_encoder() tat aber drei Mal das Gegenteil:

1. cpu-x264 und cpu-x265 standen fest verdrahtet in der Liste ("immer
   dabei"). Ein Rip-Worker OHNE HandBrake behauptete damit, komprimieren zu
   koennen; jeder Transcode dort endete sofort mit "nicht installiert".
2. 'vaapi' wurde allein wegen /dev/dri gemeldet, ohne zu pruefen, ob
   HandBrake das ueberhaupt kann. Auf der VM gemessen: das Worker-Image
   kennt svt_av1/x264/x265/mpeg4/mpeg2/VP8/VP9/theora und KEINEN einzigen
   Hardware-Encoder. Rippy haette VAAPI versprochen und dann versagt.
3. Ueber die Rechenleistung sagte es gar nichts. Genau deshalb war nicht zu
   sehen, dass ein 4K-Encode auf dieser Maschine Tage braucht: CPU-Modell
   ist das generische "QEMU Virtual CPU version 2.5+", grep -c avx2
   /proc/cpuinfo = 0, nur bis sse4_2. x265 lebt von AVX2. Gemessen an der
   Leseposition des Quellstroms: 28-55 h fuer einen Film, 3,84 von 4 Kernen
   gesaettigt. Abhilfe waere der CPU-Typ 'host' in Proxmox.

Jetzt wird die Encoder-Liste aus `HandBrakeCLI --help` geparst (Abschnitt
-e/--encoder, Formatstrings im Worker-Image gemessen - AGENTS Regel D), und
Hardware zaehlt nur, wenn Geraet UND HandBrake-Unterstuetzung da sind. Neu
gemeldet: cpu-av1 (svt_av1 ist wirklich verfuegbar) sowie CPU-Modell,
Kernzahl und Vektorbefehlsstufe je Worker.

UI: Kerne/Vektorbefehle stehen bei jedem Worker (Worker-Tab und
Einstellungen -> System), dazu die ungefilterte HandBrake-Auskunft und eine
sichtbare Warnung, wenn AVX2 fehlt - inklusive des Hinweises auf den
VM-CPU-Typ. Der Warntext liegt in lib/encoder.ts, damit er nicht doppelt
im Code steht.

Mit im gleichen Zug (dieselbe Datei): der Schalter "Alle Tracks rippen" ist
entfallen. Er war ein Placebo - abcde bekommt keine Track-Auswahl und es gab
auch keine Oberflaeche, um eine Teilmenge zu waehlen. Eine Audio-CD wurde
also immer vollstaendig gerippt, egal wie der Schalter stand. An seiner
Stelle steht jetzt die Wahrheit.

7 Tests, Testdaten sind echte HandBrake-Ausgaben von der VM. Der Parser ist
zusaetzlich gegen die vollen 697 Zeilen der echten --help gegengeprueft.

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

docker/ui/src/lib/encoder.ts

@@ -0,0 +1,24 @@
+// Encoder-Fähigkeiten eines Workers in Klartext übersetzen.
+//
+// Befund 25.07.2026: Die Rippy-VM lief auf dem generischen QEMU-CPU-Modell
+// („QEMU Virtual CPU version 2.5+") und hatte deshalb kein AVX2, nur sse4_2.
+// x265 lebt von diesen Vektorbefehlen — ein 4K-Encode brauchte dort gemessene
+// 28-55 Stunden, und nirgends im UI war das zu sehen. Der Worker meldet die
+// Angaben seit dieser Runde selbst (worker/caps.py), hier werden sie gedeutet.
+
+// Stufen, mit denen Software-Encoding brauchbar schnell ist.
+export const SIMD_SCHNELL = ['avx512f', 'avx2']
+
+/**
+ * Warnt, wenn die CPU dieses Workers zu schwach für Software-Encoding ist.
+ * Gibt null zurück, wenn alles in Ordnung ist ODER die Stufe unbekannt ist —
+ * lieber nichts sagen als etwas Falsches behaupten.
+ */
+export function simdWarnung(simd?: string): string | null {
+  if (!simd || simd === 'unbekannt') return null
+  if (SIMD_SCHNELL.includes(simd)) return null
+  return `Diese CPU kann nur ${simd} (kein AVX2) — Software-Encoding ist hier `
+    + 'sehr langsam. Bei einer virtuellen Maschine hilft es meist, den '
+    + 'CPU-Typ auf "host" zu stellen; sonst besser einen Worker mit '
+    + 'Hardware-Encoder wählen.'
+}