feat(transcode): ein HandBrake-Preset je Disc-Typ statt eines fuer alles

Rueckfrage des Commanders beim ersten echten UHD-Rip: "merkt Rippy, dass es
eine UHD ist, und nimmt direkt das 4K-Preset?" Antwort war nein. Die
Kompression fragte den Disc-Typ ueberhaupt nicht:

    preset = einstellungen.get("transcodePreset") or DEFAULT_HB_PRESET

Live eingestellt war "HQ 1080p30 Surround". Der gerade laufende Akira-Rip
waere also verlustfrei in 4K gerippt und danach auf 1080p heruntergerechnet
worden - und mit keepOriginal=False waere der 4K-Rohschnitt danach geloescht
worden. Umgekehrt wurde eine DVD auf 1080p hochskaliert, was nichts bringt.

- preset_fuer(disc_type, einstellungen) in ripping.py, pure und getestet.
  Reihenfolge: Preset des Disc-Typs -> allgemeines transcodePreset ->
  DEFAULT_HB_PRESET. Bestandsinstallationen aendern ihr Verhalten NICHT,
  solange die neuen Felder nicht gespeichert sind.
- Drei Einstellungen: transcodePresetDvd / transcodePresetBluray /
  transcodePresetUhd. transcodePreset bleibt als Rueckfall bestehen.
- transcode_files holt den Disc-Typ aus dem Job-Datensatz und schreibt ihn
  mit ins Log ("Disc-Typ 'uhd', Preset '...'").
- UI: drei Auswahlfelder statt einem, mit Klartext dazu, warum eine 4K-UHD
  auf ein 2160p-Preset gehoert.

Preset-Namen stammen aus "HandBrakeCLI --preset-list" im Worker-Image
(HandBrake 1.6.1) - nicht aus dem Kopf (AGENTS Regel D):
H.265 MKV 2160p60 4K, HQ 2160p60 4K HEVC Surround,
Super HQ 2160p60 4K HEVC Surround, H.265 MKV 1080p30, HQ 1080p30 Surround,
Super HQ 1080p30 Surround, H.265 MKV 576p25, H.265 MKV 480p30,
HQ 576p25 Surround.

Sofortmassnahme am laufenden Job (auf Ansage des Commanders): keepOriginal
auf True gesetzt - nur dieses eine Feld, gegengeprueft dass kein anderer
Schluessel veraendert wurde. Damit ueberlebt der 4K-Rohschnitt die
Kompression.

ACHTUNG - Deploy bewusst NICHT ausgefuehrt: docker compose up -d --build
wuerde den Worker-Container neu erstellen und den laufenden Akira-Rip
abbrechen. Erst nach Abschluss des Jobs deployen.

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

ROADMAP.md

@@ -541,6 +541,35 @@ completed", `TCOUNT:5`, fünf Titel, identisch zum Windows-Ergebnis.
 
 ---
 
+## Etappe 19 (25.07.2026): Preset je Disc-Typ
+
+**Quelle:** Rückfrage des Commanders beim ersten echten UHD-Rip („merkt
+Rippy eigentlich, wenn es eine UHD-Disc ist, und wendet direkt das
+4K-Preset an?"). Antwort war: nein. Die Kompression fragte den Disc-Typ
+gar nicht — ein globales `transcodePreset` galt für alles, live eingestellt
+`HQ 1080p30 Surround`. Der laufende 4K-Rip wäre danach auf 1080p
+heruntergerechnet und der Rohschnitt gelöscht worden (`keepOriginal: False`).
+
+**Gebaut:**
+- [x] **`preset_fuer(disc_type, einstellungen)`** in `ripping.py` — pure
+      Funktion, drei Tests. Reihenfolge: Preset des Disc-Typs → allgemeines
+      `transcodePreset` → `DEFAULT_HB_PRESET`. Bestandsinstallationen
+      ändern ihr Verhalten NICHT, solange die neuen Felder ungespeichert sind.
+- [x] **`transcode_files`** holt den Disc-Typ aus dem Job-Datensatz und
+      schreibt ihn mit ins Log („Disc-Typ 'uhd', Preset '…'").
+- [x] **UI**: drei Auswahlfelder (DVD / Blu-ray / 4K-UHD) statt einem, mit
+      Erklärung, warum 4K auf ein 2160p-Preset gehört. Preset-Namen aus
+      `HandBrakeCLI --preset-list` im Worker-Image belegt, nicht geraten.
+- [x] **Sofortmaßnahme am laufenden Job**: `keepOriginal` auf `True`, damit
+      der 4K-Rohschnitt die Kompression überlebt.
+
+**Offen aus dieser Runde:**
+- [ ] **Deploy steht aus** — er würde den laufenden Akira-Rip abbrechen.
+      Erst nach Abschluss des Jobs deployen, dann bei Bedarf „Neu
+      komprimieren" mit dem 4K-Preset.
+
+---
+
 ## Ideen-Katalog (Rest) — bewusst offen
 
 1. **Design 2.0** — an Gemini übergeben (24.07.2026). Vollständiges