docs(savepoint): v3.15 - Aufraeum-Runde mit gemessenen Zahlen

Fuenf Vorgaben, was daraus wurde:

Codebase sauber   -> vier tote Routen + zwei Module weg (main.py 1726 -> 1682
                     Zeilen), Tests halten sie draussen
UI schnell        -> /capabilities 1,010 s -> 0,003 s; Dashboard-Aufbau
                     1,03 s -> 0,028 s. Alle 15 Ladeendpunkte unter 10 ms
UI selbsterklaerend -> Wizard-Kasten "Was Rippy gerade sieht" mit
                     Handlungsanweisung je Problem, sichtbare Keys mit Pruefung
Idiotensicher     -> Wizard empfiehlt nach GEMESSENER CPU statt H.265 blind;
                     4K-Falle ist damit zu
Externe Worker    -> auf Windows gegengeprueft (Kerne/Modell korrekt, encoders
                     ohne HandBrake korrekt leer, SIMD ehrlich "unbekannt")

Dazu die offene 4K-Frage aus v3.14 beantwortet: Kompression ist je Disc-Typ
abwaehlbar, 4K kann verlustfrei bleiben waehrend DVD/Blu-ray weiter schrumpfen.

ARM-Vergleich drin: fast alles, was ARM automatisch macht, macht Rippy schon -
und meist gruendlicher. Zwei echte Luecken benannt und NICHT gebaut
(ISO-Sicherung fuer Datentraeger, mehrere Laufwerke gleichzeitig), weil das
Funktionen sind und keine Reparatur. Ehrlich dabei: ob Rippy parallel rippen
kann, ist unbewiesen - mit einem Laufwerk nicht testbar.

Offene Punkte stehen unter "NOCH OFFEN", darunter der VM-CPU-Typ (qemu64 statt
host - AVX2 waere ein VM-Neustart und 2-4x schneller).

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

AGENTS.md

@@ -70,6 +70,9 @@ Bibliotheks-APIs: `--help`/Doku prüfen und die Fundstelle im Commit nennen.
   (Fortschritt log, Auswurf tat nichts, „Alle Tracks" konnte nichts, Encoder
   wurden behauptet statt gemessen), Zombie-Erkennung gebaut, Pfad-Prüfung
   gehärtet, und der Platten-Schutz aus `c065967` als **unwirksam** entlarvt
+- ✅ **Etappe 20 (v3.15):** Aufräum-Runde — `/capabilities` 1,010 s → 0,003 s
+  (Ping im Hintergrund), Kompression je Disc-Typ abwählbar (4K verlustfrei),
+  Wizard empfiehlt nach gemessener CPU, vier tote Routen entfernt
 - 📝 **Details immer in SAVEPOINT.md** — diese Sektion nennt nur die Etappe
 
 ## Was diese Sitzungen wiederholt gekostet hat

SAVEPOINT.md

@@ -1,6 +1,115 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v3.14 — Durchsicht: vier Placebos und ein unwirksamer Schutz (25.07.2026, 18:40)
+## Aktueller Stand: v3.15 — Aufräum-Runde: Tempo, tote Routen, 4K-Entscheidung (25.07.2026, 20:00)
+
+> **Deployt und live gegengeprüft.** Auftrag war „bau alles so um, dass es
+> sauber ist" mit fünf Vorgaben: saubere Codebase, selbsterklärendes UI,
+> externe Worker, kein Laggen, idiotensicher. Was noch offen ist, steht unten.
+
+### Das „Laggen" hatte genau eine Ursache — gemessen und behoben
+
+Über alle 15 Endpunkte gemessen, die das UI beim Laden braucht:
+
+| Endpunkt | vorher | nachher |
+|---|---|---|
+| `/capabilities` | **1,010 s** | **0,003 s** |
+| `/system/updates` | 0,491 s | unverändert (hängt am Knopf) |
+| `/metadata/status` | 0,412 s | unverändert (hängt am Knopf) |
+| die anderen 12 | < 0,025 s | < 0,010 s |
+
+Nur `/capabilities` schlug beim **Seitenaufbau** zu — und fünf Stellen holen
+ihn (Dashboard, Einstellungen, Worker-Tab, Wizard, Rip-Dialog). Jede Seite
+zahlte eine Sekunde. Ursache ist kein Fehler, sondern das Wesen des
+Celery-Pings: er sammelt Antworten bis zum Timeout und kann nicht früher
+aufhören. Den Timeout zu kürzen würde Antworten langsamer Remote-Worker
+verschlucken — also genau die Maschinen, um die es beim externen Encoding geht.
+Jetzt pingt eine Hintergrund-Schleife im 5-s-Takt, der Endpunkt liest ab. Ist
+der Vorrat älter als 30 s, wird einmal synchron gepingt: lieber langsam als
+falsch („alles offline", obwohl alles läuft). Kompletter Dashboard-Aufbau:
+**1,03 s → 0,028 s.**
+
+### 4K ist entschieden — Kompression je Disc-Typ abwählbar
+
+Die offene Frage aus v3.14 ist gebaut. Bisher gab es nur `transcodeEnabled`:
+alles oder nichts. Jetzt kann das Preset eines Disc-Typs auf den Reservewert
+`keine` stehen → die verlustfreie Datei bleibt stehen. Damit ist die sinnvolle
+Einstellung für diese Maschine erstmals möglich: **4K verlustfrei behalten,
+DVD und Blu-ray weiter schrumpfen.**
+
+`komprimieren_fuer()` ist die neue reine Funktion; `preset_fuer()` überspringt
+den Reservewert bewusst und gibt ihn NIE als Preset-Namen zurück — sonst bekäme
+HandBrake `--preset keine`. Gegengeprüft: keiner der 90 echten Presets aus
+`--preset-list` heißt so, und die fünf im UI angebotenen Namen existieren alle.
+
+### Der Wizard läuft nicht mehr in die 4K-Falle
+
+Er hatte die Zahlen längst vorliegen (`/capabilities` meldet `cpu_simd` und
+`cpu_kerne`) — benutzt hat er sie nicht und H.265 als Standard vorgeschlagen.
+Auf einer CPU ohne AVX2 sind das ein bis zwei Tage pro 4K-Film.
+
+Jetzt entscheidet die **gemessene** Leistung: schwache CPU → 4K nicht
+komprimieren, Blu-ray/DVD auf H.264. Stark oder Hardware-Encoder → H.265
+durchgehend. Und er schreibt **alle vier** Preset-Felder statt nur des
+allgemeinen; vorher fiel 4K auf ein 1080p-Preset zurück.
+
+Dazu gehärtet: Kasten „Was Rippy gerade sieht" (Laufwerk, Worker mit
+Kernen/SIMD, freier Platz) — jede Zeile mit **Handlungsanweisung** statt nur
+einem Kreuz. Lädt parallel und wiederholt im 5-s-Takt, weil der Worker beim
+ersten Start noch hochläuft. API-Keys sind sichtbar statt Punkte (kopierte
+Keys, keine Passwörter — Tippfehler sieht man in Punkten nicht) und werden
+direkt nach dem Speichern geprüft, mit der Wahl „Key korrigieren" oder
+„Trotzdem fertigstellen".
+
+**Gewarnt wird nur, wenn es belegt ist:** `schwacheEncoderCpu()` verlangt
+mindestens einen Worker mit BEKANNTER SIMD-Stufe und keinen mit
+Hardware-Encoder. Ein Windows-Worker meldet `unbekannt` (kein `/proc/cpuinfo`)
+→ dann wird geschwiegen statt falsch gewarnt.
+
+### Vier tote Routen raus
+
+`POST /prescan`, `POST /jellyfin/format` (+ `nfo_generator.py` und
+`image_downloader.py`, die sonst nichts nutzte), `GET /stream/jobs`,
+`GET /worker-setup/windows-gui`. Jede ein Überrest eines ersetzten Entwurfs,
+keine mit Aufrufer. `main.py`: 1726 → 1682 Zeilen, dazu 279 Zeilen in zwei
+gelöschten Modulen. Tests halten beide Seiten fest: die vier müssen WEG
+bleiben, die drei für die Worker-Installation (`/worker-setup/paket`,
+`/windows`, `/windows-exe`) müssen DA sein.
+
+### Externe Worker — vorbereitet, vom Commander zu testen
+
+Auf **Windows gegengeprüft** (dieser PC): `cpu_kerne` 16 und CPU-Modell kommen
+korrekt durch, `encoders` ist ohne installiertes HandBrake korrekt **leer**,
+`cpu_simd` ehrlich `unbekannt` → keine falsche Warnung. Ein GPU-Worker braucht
+ein HandBrake-Build mit `nvenc_*`/`qsv_*`; die neue Anzeige nennt die
+ungefilterte HandBrake-Auskunft, damit das nachprüfbar ist.
+
+### ARM-Vergleich (Vorbild-Projekt)
+
+Fast alles, was ARM automatisch macht, macht Rippy schon — und meist
+gründlicher: Metadaten aus drei Quellen statt nur OMDb, Episoden-Erkennung per
+Laufzeitabgleich, Kompression auf eine eigene Queue routbar. Bezeichnend:
+ARMs Auto-Auswurf war bei Rippy nur **behauptet** und ist erst in v3.14 echt
+geworden. Zwei Lücken bleiben, beide **nicht gebaut, als Vorschlag**:
+- **ISO-Sicherung** für Datenträger, die weder Film noch Audio-CD sind — daran
+  scheitert Rippy heute.
+- **Mehrere Laufwerke gleichzeitig.** Rippy sieht sie (`/dev/sr[0-9]*`), ob
+  parallel gerippt wird, ist **unbewiesen** — mit einem Laufwerk nicht testbar.
+
+### NOCH OFFEN
+
+1. **Externe Worker im Praxistest** (Commander).
+2. **ISO-Sicherung und Mehr-Laufwerk-Betrieb** — siehe ARM-Vergleich.
+3. **„Job aus der Liste entfernen" sagt nicht, wie viel daneben liegen bleibt**
+   (v3.14). Der Rohschnitt verwaist dabei unsichtbar.
+4. **Discord-Webhook und MakeMKV-Key liegen im Klartext** in der
+   settings-Tabelle. Für Heimnetz erwartbar, aber der Webhook ist eine echte
+   Zugangsberechtigung.
+5. **Der VM-CPU-Typ steht auf `qemu64`.** `host` würde AVX2 freischalten und
+   jeden Software-Encode 2–4× beschleunigen. Ein VM-Neustart, nicht gemacht.
+
+---
+
+## Vorheriger Stand: v3.14 — Durchsicht: vier Placebos und ein unwirksamer Schutz (25.07.2026, 18:40)
 
 > **Stand 19:30: alles committet, Ampel grün (`a1aabd5`), DEPLOYT und live
 > gegengeprüft.** Der Akira-Encode wurde um 18:31 abgebrochen (Nachtrag im