fix(transcode): "Abbrechen" wirkt sofort statt erst beim naechsten Prozent

Fund des Commanders am laufenden Akira-Job (Nachtrag im vorigen Savepoint):
Job stand auf 'canceling', HandBrake lief weiter. Gemessen 3,4 Minuten
zwischen Anforderung (18:30:17) und Bestaetigung (18:33:38) - bei langsamerem
Fortschritt entsprechend mehr.

Ursache genau wie dort beschrieben: Der Abbruch wurde nur in
datei_fortschritt geprueft, und diese Closure stieg oben sofort wieder aus,
wenn sich die Prozentzahl nicht geaendert hatte ("if gesamt == letzter[0]:
return"). Bei einem Prozent je halber Stunde hing der Abbruch also an einem
Ereignis, das eine halbe Stunde lang nicht eintrat.

run_handbrake bekommt jetzt einen eigenen abbruch_cb neben progress_cb -
dasselbe Muster, das run_makemkv schon fuer log_cb benutzt, und aus
demselben Grund: der Fortschritts-Kanal verwirft Aufrufe. Er wird bei JEDER
Ausgabezeile aufgerufen und im Worker auf 5 s gedrosselt.

Nebeneffekt, der genauso wichtig ist: Er greift auch waehrend des
Scan-Durchlaufs, der ueberhaupt keine Encode-Prozente liefert. Dort war ein
Abbruch vorher grundsaetzlich unmoeglich - und seit die Prozent-Regex den
Scan korrekt ignoriert, waere das sonst sogar schlimmer geworden.

Die Leseschleife ist als _handbrake_schleife() herausgezogen, damit die
Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake pruefbar ist.
Der Test belegt: zwei Scan-Zeilen genuegen fuer den Abbruch, es muss NICHT
auf eine Encode-Zeile gewartet werden.

Savepoint nachgezogen: Der Encode laeuft nicht mehr, ein Deploy ist
gefahrlos moeglich, und die alte "SOFORT ENTSCHEIDEN"-Passage (Platte
laeuft voll, wenn der Job fertig wird) ist damit gegenstandslos. Neu darin:
die drei Wege fuer UHD, und die Warnung, dass eine /proc-Suche nach
"HandBrake" die eigene Shell mittrifft - zwei Fehlalarme in dieser Sitzung.

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

SAVEPOINT.md

@@ -2,9 +2,10 @@
 
 ## Aktueller Stand: v3.14 — Durchsicht: vier Placebos und ein unwirksamer Schutz (25.07.2026, 18:40)
 
-> Diese Sitzung hat nichts deployt (der Akira-Encode läuft — ein Rebuild
-> schießt ihn ab). Alles unten ist committet und die Ampel ist grün.
-> **Zuerst lesen: „SOFORT ENTSCHEIDEN" ganz unten.**
+> Alles unten ist committet, die Ampel ist grün, **nichts ist deployt**.
+> Der Akira-Encode wurde parallel zu dieser Sitzung um 18:31 abgebrochen
+> (siehe Nachtrag im Block darunter) — **es läuft jetzt nichts mehr, ein
+> Deploy ist gefahrlos möglich.** Zuerst lesen: „SOFORT ENTSCHEIDEN" unten.
 
 ### DER WICHTIGSTE FUND: der Platten-Schutz aus `c065967` greift nicht
 
@@ -35,11 +36,16 @@ Falls, der die Platte füllte.
   18:00:39 (Deploy von `8bb075c`), postgres/redis älter.
 - **Platte:** 148 G, 105 G belegt, 37 G frei = 75 G Rohschnitt + 4,9 G Medien
   (Evangelion) + ~25 G System. **Keine Kopier-Reste**, kein `original`-Ordner.
-- **Akira-Encode läuft:** HandBrake PID 40 seit 18:01:37, Preset
-  `H.265 MKV 2160p60 4K`, **3,84 von 4 Kernen**. Leseposition im Quellstrom
-  **1.145.940.149 von 79.604.951.639 Bytes = 1,44 %**.
-- **Restlaufzeit ≈ 28–55 h.** Zwei Messfenster ergaben 395 und 784 KB/s — das
-  Tempo schwankt mit der Bildkomplexität, deshalb eine Spanne und keine Zahl.
+- **Akira-Job:** `failed`, „Abgebrochen durch Nutzer" (Abbruch 18:30:17
+  angefordert, Worker bestätigt 18:33:38 → **3,4 Minuten Verzug**, siehe unten).
+  Es läuft **kein** HandBrake mehr (per `/proc` geprüft, Stand 19:06).
+- **Der Encode war bei 1,44 %**, gemessen an der Leseposition im Quellstrom
+  (`/proc/<pid>/fdinfo/3`: 1.145.940.149 von 79.604.951.639 Bytes) — exakter
+  als jede Fortschrittsanzeige. Zwei Tempo-Fenster ergaben 395 und 784 KB/s
+  → **28–55 h** für den Film, bei 3,84 von 4 gesättigten Kernen.
+- **Achtung bei Prozess-Suchen per `/proc`:** Ein `case "$c" in *HandBrake*)`
+  trifft die eigene Shell mit, weil deren Kommandozeile das Wort enthält. Zwei
+  Fehlalarme in dieser Sitzung. Immer die PID gegenprüfen.
 - **Die Ursache dafür ist neu und behebbar:** Die VM läuft auf dem generischen
   QEMU-CPU-Modell (`QEMU Virtual CPU version 2.5+`), `grep -c avx2
   /proc/cpuinfo` = **0**, nur bis `sse4_2`. x265 lebt von AVX2. Abhilfe:
@@ -138,26 +144,52 @@ entscheidet.**
 - **Zwei neue API-Tests laufen nur in der Ampel** — `test_api_smoke.py`
   überspringt sich unter Windows selbst (`main.py` braucht `fcntl`).
 
+### GEBAUT — „Abbrechen" wirkt jetzt sofort
+
+Der Fund aus dem Nachtrag (Commander, am laufenden Job beobachtet) ist behoben.
+Ursache war genau wie dort beschrieben: Der Abbruch wurde nur in
+`datei_fortschritt` geprüft, und diese Closure stieg oben sofort wieder aus,
+wenn sich die Prozentzahl nicht geändert hatte. Bei einem Prozent je halber
+Stunde sah „Abbrechen" entsprechend lange wirkungslos aus.
+
+Jetzt gibt es in `run_handbrake` einen **eigenen Abbruch-Kanal** neben dem
+Fortschritts-Callback — dasselbe Muster, das `run_makemkv` schon für `log_cb`
+benutzt, und aus demselben Grund. Er wird bei JEDER Ausgabezeile aufgerufen
+und ist im Worker auf 5 Sekunden gedrosselt (`ABBRUCH_INTERVALL_SEKUNDEN`).
+Nebeneffekt: Er greift auch während des Scan-Durchlaufs, der überhaupt keine
+Encode-Prozente liefert — dort war ein Abbruch vorher grundsätzlich unmöglich.
+Die Leseschleife ist als `_handbrake_schleife()` herausgezogen, damit die
+Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake testbar ist.
+
 ### SOFORT ENTSCHEIDEN
 
-**Der laufende Job wird beim Fertigwerden mit dem DEPLOYTEN (alten) Code
-versuchen, 75 GB in 37 GB zu kopieren.** `keepOriginal` steht auf `true`, und
-den Wert hat die Aufgabe beim Start um 18:01:37 gelesen — ihn jetzt umzustellen
-ändert für diesen Lauf nichts mehr. Der Ablauf wäre: Platte läuft auf 100 %,
-dann ENOSPC, dann räumt der `except`-Zweig die Teilkopie weg. Selbstheilend —
-aber währenddessen ist die Systemplatte voll, und genau daran hat sich heute
-Mittag der Worker-Container verschluckt.
+**1. Deployen — es läuft nichts, der Weg ist frei.** Nichts blockiert mehr, und
+solange nicht deployt ist, gilt weiterhin der alte Code: unwirksamer
+Platten-Schutz, Anzeige auf 99 %, Auswurf ohne Wirkung, träges „Abbrechen".
 
-Die Optionen, in der Reihenfolge, die ich empfehle:
+```
+ssh arcane@192.168.178.162 'cd ~/projects/rippy && git pull --ff-only && docker compose up -d --build'
+```
 
-1. **Encode abbrechen, deployen, Kompression neu anstoßen.** Kostet die
-   bisherigen ~30 Minuten (der Lauf ist bei 1,44 % — praktisch nichts) und
-   bringt sofort alle Fixes live, inklusive des Platten-Schutzes und der
-   ehrlichen Fortschrittsanzeige. Wer ohnehin über den CPU-Typ nachdenkt,
-   erledigt das im selben Fenster.
-2. **Laufen lassen und in 1–2 Tagen deployen**, vorher die 75 GB von Hand
-   wegräumen oder auf die NAS schieben, damit die Kopie nicht anlaufen kann.
-3. **Laufen lassen und den vollen Plattenlauf in Kauf nehmen.**
+**2. Die UHD-Strategie ist noch offen** (aus dem Nachtrag, unverändert gültig).
+Preset-je-Disc-Typ war richtig, reicht aber nicht: Software-HEVC in 4K ist auf
+dieser CPU keine Option. Drei Wege, keiner davon gebaut:
+- **UHD gar nicht komprimieren** — Roh-MKV behalten. Ehrlichste Variante,
+  kostet Platz (75–100 GB je Film, gehört dann auf die NAS).
+- **Hardware-Encoder** — Remote-Worker mit GPU (`nvenc`/`vaapi`). Rippy kann
+  das schon routen (bewiesen v3.7); es fehlt die Maschine. Achtung: Das
+  Worker-Image kann selbst keinen Hardware-Encoder, ein GPU-Worker braucht ein
+  HandBrake-Build mit `nvenc_*`/`qsv_*` — die neue Anzeige sagt das jetzt.
+- **CPU-Typ der VM auf `host`** — schaltet AVX2 frei, bringt bei x265 typisch
+  Faktor 2–4. Aus 28–55 h werden damit aber immer noch Stunden bis Tage; das
+  allein löst 4K nicht, hilft aber jedem 1080p-Encode.
+
+**3. Vier tote Endpunkte** — entfernen oder behalten (Tabelle oben).
+
+**4. Im Akira-Ordner liegt ein unbrauchbares 4K-Fragment** (die 1080p-Fassung
+wurde beim Start auf 0 Bytes gekürzt). Der 75-GB-Rohschnitt ist unversehrt,
+also ist nichts verloren — aber die Datei gehört weg, bevor jemand sie für ein
+Ergebnis hält.
 
 ---