docs(savepoint): die Kette ist zum ersten Mal ganz durchgelaufen

40,9 GB Rip -> Auswurf -> Kompression auf dem Windows-PC -> 12,29 GB abgelegt,
Roh-Verzeichnis danach automatisch aufgeraeumt. Die Sprachwahl am ERGEBNIS
nachgeprueft (HandBrakeCLI --scan auf die abgelegte Datei): nur noch deutsche
Ton- und Untertitelspuren, kein Japanisch, keine unbenannten - vorher meldete
der Disc-Scan deu 4x, jpn 2x, und 4x.

Ein Fund aus dem Ergebnis, bewusst NICHT still repariert: Der Ton ist fuenfmal
MP3 2.0 mit 160 kbps. Das Preset "HQ 1080p30 Surround" schreibt laut
--preset-export zwei Regeln vor (av_aac stereo 160 / Surround 640); angewandt
wurde nur die erste, auf jede behaltene Spur. Der Surround-Ton eines Presets
namens "Surround" faellt damit still weg. Warum der Encoder MP3 statt av_aac
wurde, ist ungeklaert - Rippy uebergibt keinen Audio-Schalter. Als offener
Punkt notiert statt geraten; die Preset-Wahl ist eine Entscheidung des
Commanders.

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

SAVEPOINT.md

@@ -12,7 +12,7 @@
 |---|---|
 | Repo + VM | `96c400f`, Ampel **grün**, deployt |
 | Tests | **301** grün (Sitzungsbeginn heute: 130) |
-| Voller Durchlauf | Rip 40,9 GB ✅ · Auswurf ✅ · Übergabe an den PC ✅ · Kompression läuft |
+| Voller Durchlauf | **komplett durch**: 40,9 GB Rip → Auswurf → Kompression auf dem PC → 12,29 GB abgelegt |
 | Rate-Limit-Eimer | PC bei 590, VM gleichzeitig bei 599 — **getrennt** (vorher einer für alle) |
 | Anfragen des Dashboards | 75/min → **30/min** |
 | Phasen-Marke | live gesetzt: `rip_fertig: false` beim Rip-Start |
@@ -226,12 +226,59 @@ durch. Jetzt zwölf (`test_erreichbarkeit.py`). Beim Schreiben fiel ein dritter
 Fehler auf: `isdir=os.path.isdir` als Vorgabewert bindet die Funktion beim
 IMPORT; ein Ersetzen geht danach ins Leere. Auflösung jetzt beim Aufruf.
 
+**Das Ergebnis nach der Reparatur — die Kette ist zum ersten Mal ganz
+durchgelaufen:**
+
+```
+16:47:57  abgeschlossen → \\192.168.178.62\rippy\movies\Akira (1988)
+```
+
+40,9 GB roh → **12,29 GB** fertig (63 Minuten auf dem Ryzen 9700X), das
+Roh-Verzeichnis danach automatisch aufgeräumt. Die Sprachwahl am fertigen
+Ergebnis nachgeprüft (`HandBrakeCLI --scan` auf die abgelegte Datei):
+
+```
++ audio tracks:
+    + 1..5, Deutsch (MP3, 2.0 ch, 160 kbps) (iso639-2: deu)
+  + subtitle tracks:
+    + 1, Deutsch (PGS)
+    + 2, Deutsch (PGS)
+```
+
+Kein Japanisch, keine unbenannten Spuren — vorher meldete der Scan der Disc
+`Ton: deu 4×, jpn 2×, und 4×` und `Untertitel: deu 4×, und 8×`. **Die
+Sprachwahl greift also wirklich, bis in die abgelegte Datei.**
+
+### 5b. Ein Fund aus dem Ergebnis: „Surround" liefert Stereo
+
+Der Ton der fertigen Datei ist **fünfmal MP3 2.0 mit 160 kbps** — von einer
+Blu-ray. Das gewählte Preset heißt `HQ 1080p30 Surround`; ausgelesen mit
+`--preset-export` schreibt es vor:
+
+| Regel | Encoder | Mixdown | Bitrate |
+|---|---|---|---|
+| AudioList[0] | `av_aac` | stereo | 160 |
+| AudioList[1] | (Surround) | — | 640 |
+
+Angewandt wurde nur Regel 0 — auf JEDE der fünf behaltenen Spuren. Regel 1 hat
+nie eine Spur erzeugt. Der Surround-Ton eines Presets namens „Surround" fällt
+damit still weg, und die Bitrate deckelt bei 160 kbps.
+
+Warum der Encoder MP3 statt `av_aac` wurde, ist **nicht geklärt** — Rippy
+übergibt keinen Audio-Schalter, nur `--audio-lang-list` und `--all-audio`.
+Bitrate und Mixdown stimmen exakt mit Regel 0 überein, nur der Codec nicht.
+Nicht geraten, sondern als offener Punkt notiert.
+
+**Zu entscheiden ist das vom Commander**, nicht still von mir: Für ein Archiv
+wäre ein Preset mit Surround-Durchreichung richtig (die `H.265 MKV`-Reihe), oder
+weniger Tonspuren behalten. Ich habe nichts umgestellt.
+
 ### 6. Was noch offen ist
-- **Job `2182d525` trägt einen falschen Fehlertext.** Das Aufräumen lief, bevor
-  der phasenbewusste Text deployt war; dort steht noch „mit ‚Neu komprimieren'
-  läuft die Kompression erneut" für einen Rip, der bei 12 % starb. Der Knopf
-  fragt inzwischen nach, der Text im Detail-Popup lügt weiter. Der Eintrag samt
-  4,8-GB-Bruchstück kann über den Papierkorb weg — der Neu-Rip ersetzt ihn.
+- **Der Ton-Befund aus 5b** — Preset-Wahl, Entscheidung des Commanders.
+- ~~Job `2182d525` mit falschem Fehlertext~~ — **erledigt**: Der Commander hat
+  den Eintrag am 26.07. um 16:35 samt 4,8-GB-Bruchstück über den Papierkorb
+  entfernt (`aus der Liste entfernt (inkl. 4.8 GB Rohdaten gelöscht)`). Damit
+  ist nebenbei auch der Lösch-Dialog mit Rohdaten-Wahl im echten Betrieb belegt.
 - **`sudo ./install.sh` auf einem FRISCHEN Host ist weiter unbelegt.** Der
   Prüfpfad (`--nur-pruefen`) läuft auf der VM sauber durch, alle fünf Prüfungen
   grün. Ein echter Root-Lauf hier hätte den laufenden Rip getötet.