fix(bg): Hintergrundarbeit reisst den Prozess nicht mehr mit

Das Vorschaubild entstand in einer nackten Goroutine. Chis Recoverer haengt
am Anfragebehandler und sieht davon nichts -- eine Panik im Bilddekodierer
nahm den ganzen Go-Prozess mit, ausgeloest durch einen gewoehnlichen
Upload. Die Bibliothek ist seit ef60497 aktuell; das schloss **diese**
Luecke. Dies hier schliesst die **Gattung**.

pkg/bg mit zwei Funktionen, und der Unterschied ist keine Feinheit:

* bg.Go(name, fn)  -- Goroutine, die eine Panik ueberlebt
* bg.Run(name, fn) -- dasselbe ohne eigene Goroutine, fuer Schleifen

Faengt man eine Panik um den **ganzen** Arbeiter ab, ueberlebt der Prozess
-- aber der Arbeiter ist tot, und von da an wird still keine Datei mehr
erkannt. Der OCR-Arbeiter sichert deshalb jeden **Auftrag** einzeln ab.

Umgestellt: Vorschaubild, Bestand nachtragen, Freigabe-Zaehler,
Speicherbereinigung, OCR-Arbeiter. Eine nackte Goroutine bleibt mit
Begruendung im Code -- die Signalbehandlung; ein recover braechte dort
nichts, weil main ohnehin wartete.

Aufgefangene Paniken werden mit Stapel und Herkunft protokolliert. Vier
Tests, darunter der wichtige: Eine Schleife laeuft nach einer Panik im
dritten Durchgang weiter.

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

BEFUNDE.md

@@ -39,11 +39,28 @@ es: `internal/sharing/handler.go:232` und `main.go:185` (beide nur Datenbank,
 harmlos), `internal/gc/gc.go:257`, und der OCR-Arbeiter (`go worker.Run(ctx)`),
 der Fremdprogramme aufruft und deren Ausgabe liest.
 
-**Vorschlag:** Ein kleines `sicher(func())` in `pkg/middleware` oder daneben,
-das `recover()` macht und die Panik protokolliert, statt sie durchzulassen —
-und alle Hintergrund-Goroutinen darüber starten. Fünf Zeilen, eine Stelle.
+**✅ Erledigt am 12.09.2026.** `pkg/bg` mit zwei Funktionen:
 
-> Der Unterschied ist wichtig: Die Version zu heben schließt **diese** Lücke.
+* `bg.Go(name, fn)` – startet eine Goroutine, die eine Panik überlebt.
+* `bg.Run(name, fn)` – dasselbe ohne eigene Goroutine, für Schleifen.
+
+Der Unterschied ist keine Feinheit: Fängt man eine Panik um den **ganzen**
+Arbeiter herum ab, überlebt der Prozess – aber der Arbeiter ist tot, und von da
+an wird still keine Datei mehr erkannt. Der OCR-Arbeiter sichert deshalb jeden
+**Auftrag** einzeln ab; ein unverdauliches Dokument kostet dann genau sich
+selbst.
+
+Umgestellt: Vorschaubild, Bestand nachtragen, Freigabe-Zähler,
+Speicherbereinigung, OCR-Arbeiter. Eine nackte Goroutine bleibt mit Begründung
+im Code – die Signalbehandlung beim Herunterfahren; ein recover brächte dort
+nichts, weil `main` ohnehin wartete, und sie fasst keine fremden Daten an.
+
+Eine aufgefangene Panik wird mit Stapel und Herkunftsname protokolliert. Sie
+ist ein Fehler und bleibt einer – sie reißt nur nichts mehr mit. Vier Tests in
+`pkg/bg/bg_test.go`, darunter der, auf den es ankommt: Eine Schleife läuft nach
+einer Panik im dritten Durchgang weiter.
+
+> Der Unterschied ist wichtig: Die Version zu heben schloss **diese** Lücke.
 > Der `recover` schließt die **Gattung**.
 
 ---
@@ -145,8 +162,7 @@ gibt:
 
 ## Reihenfolge, die ich vorschlagen würde
 
-1. **`recover` in die Hintergrund-Goroutinen** (Punkt 1, Rest). Klein, und es
-   schließt eine Gattung statt eines Einzelfalls.
+1. ~~`recover` in die Hintergrund-Goroutinen~~ ✅ 12.09.2026
 2. **Prüfsummen-Abweichung melden** (Punkt 2). Zehn Zeilen für eine Auskunft,
    die es sonst nie gibt.
 3. **Tests für `documents`** (Punkt 3). Das Paket, dessen stilles Versagen am