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>

SAVEPOINT.md

@@ -1,6 +1,41 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v3.11 — 4K-UHD GELÖST: Akira geht auf (25.07.2026)
+## Aktueller Stand: v3.12 — Preset je Disc-Typ (25.07.2026)
+
+- **Der Fund:** Beim ersten echten UHD-Rip aufgefallen — die Kompression
+  fragte den Disc-Typ **gar nicht**: `preset = einstellungen.get(
+  "transcodePreset")`, ein globales Preset für alles. Live eingestellt war
+  `HQ 1080p30 Surround`. Der laufende Akira-Rip wäre also verlustfrei in 4K
+  gerippt und danach **auf 1080p heruntergerechnet** worden — und mit
+  `keepOriginal: False` wäre der 4K-Rohschnitt anschließend gelöscht worden.
+  Aufgefallen ist es nur, weil der Commander gefragt hat, ob Rippy das
+  UHD-Preset automatisch nimmt.
+- **Sofortmaßnahme am laufenden Job:** `keepOriginal` auf `True` gesetzt
+  (nur dieses eine Feld, gegengeprüft: kein anderer Schlüssel verändert).
+  Damit überlebt der 4K-Rohschnitt die Kompression auf jeden Fall.
+- **Gebaut:** `preset_fuer(disc_type, einstellungen)` in `ripping.py` (pure,
+  getestet) plus drei Einstellungen `transcodePresetDvd` / `…Bluray` /
+  `…Uhd`. Reihenfolge: Preset des Disc-Typs → allgemeines
+  `transcodePreset` → `DEFAULT_HB_PRESET`. **Bestandsinstallationen ändern
+  ihr Verhalten nicht**, solange die neuen Felder nicht gespeichert sind.
+  `transcode_files` holt den Disc-Typ aus dem Job-Datensatz und schreibt ihn
+  mit ins Log.
+- **UI (Einstellungen → Verarbeitung):** drei Auswahlfelder statt einem, mit
+  Klartext dazu, warum 4K auf ein 2160p-Preset gehört. Alle Preset-Namen
+  stammen aus `HandBrakeCLI --preset-list` im Worker-Image (1.6.1) — nicht
+  geraten (AGENTS Regel D).
+- **⚠️ Deploy bewusst zurückgehalten:** `docker compose up -d --build`
+  würde den Worker-Container neu erstellen und den **laufenden Akira-Rip
+  abbrechen**. Erst deployen, wenn der Job durch ist. Der 4K-Rohschnitt ist
+  durch `keepOriginal` geschützt; danach reicht „Neu komprimieren" im UI,
+  um mit dem richtigen Preset in 4K zu komprimieren.
+- **Nebenbefund:** `ps` gibt es im Worker-Image nicht (python-slim). Frühere
+  Prüfungen auf laufende Rips per `ps | grep` lieferten deshalb still
+  „nichts aktiv" — richtig geht es über `/proc`.
+
+---
+
+## Vorheriger Stand: v3.11 — 4K-UHD GELÖST: Akira geht auf (25.07.2026)
 
 - **🎉 Der Durchbruch:** Nach Übernahme des Schlüsselspeichers öffnet
   `makemkvcon` auf der VM die Akira-UHD: „Operation successfully