fix: ein Upload durfte den ganzen Dienst umbringen -- und tat es

BEIM UEBERNEHMEN VON 3670 DATEIEN STARB DER DIENST. Nicht einmal, sondern in
Schleife: acht Neustarts, nach aussen 502 vom Proxy.

    TypeError [ERR_INVALID_STATE]: ReadableStream is already closed
        at ReadableByteStreamController.close (node:internal/webstreams/...)

DIE URSACHE WAR MEINE EIGENE AENDERUNG von vor einer Stunde. Um PowerShells
Formular-Rumpf zu vertragen, hatte ich `c.req.parseBody()` durch
`c.req.raw.formData()` ersetzt -- und damit Hono den Rumpf weggenommen, den es
selbst verwaltet. Beim Aufraeumen der Antwort schliesst dann jemand einen
Strom, der schon zu ist. Die Ausnahme faellt in einem Microtask an, also
AUSSERHALB jedes try/catch, und Node beendet den Prozess.

Beim Test mit 57 Dateien fiel das nicht auf. Bei 3670 schon.

Jetzt geht der Normalfall wieder ueber Hono; der eigene Weg gilt nur noch fuer
die Antwort mit Anfuehrungszeichen an der Grenzmarkierung, fuer die er gedacht
war.

UND EIN NETZ DARUNTER: process.on('uncaughtException') faengt, was ausserhalb
jedes try/catch anfaellt, und laesst den Dienst weiterlaufen. Die Abwaegung
steht im Code: das ist NICHT in jedem Fall richtig -- der Prozess kann danach
kaputt sein. Hier ueberwiegt das Weiterlaufen, weil dieser Dienst keinen
Zustand im Speicher haelt (alles in SQLite und auf der Platte) und ein Dienst,
der wegen EINER Anfrage fuer alle weg ist, der schlechtere Tausch waere. Laut
wird es trotzdem.

DER SCHADEN WAR REPARIERBAR, und zwar mit dem Werkzeug von heute Nachmittag:
206 Dateien waren durch, 2 lagen auf der Platte OHNE Datensatz (geschrieben,
dann starb der Prozess vor dem Eintrag), dazu eine verwaiste Vorschau. Der
Verwaisten-Finder hat sie gefunden, "aufnehmen" hat sie eingetragen -- keine
Datei verloren.

Und die Fehlermeldung im Uebernahmeskript verschwieg die Ursache: sie meldete
"Conversion from JSON failed ... Unexpected character <", obwohl die Wahrheit
ein 502 war. Jetzt wird der HTTP-Code mitgelesen, bei 502 sauber abgebrochen
und gesagt, dass ein neuer Lauf einfach weitermacht.

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

server/src/index.ts

@@ -60,6 +60,29 @@ app.onError((err, c) => {
     return c.text(`Serverfehler: ${text}`, 500)
 })
 
+// Ein Fehler AUSSERHALB jedes try/catch darf den Dienst nicht umbringen.
+//
+// Genau das ist beim Uebernehmen von 3670 Dateien passiert: undici warf
+// "ReadableStream is already closed" aus einem Microtask -- also an einer
+// Stelle, an der kein try/catch der Welt steht. Node beendet den Prozess
+// daraufhin, Docker startet ihn neu, die naechste Anfrage kippt ihn wieder:
+// eine Neustartschleife, und nach aussen 502.
+//
+// DIE ABWAEGUNG, ausgesprochen: einen unerwarteten Fehler zu ueberleben ist
+// nicht in jedem Fall richtig -- der Prozess KANN danach in einem kaputten
+// Zustand sein. Hier ueberwiegt trotzdem das Weiterlaufen: dieser Dienst haelt
+// keinen Zustand im Speicher, der verderben koennte (alles steht in SQLite und
+// auf der Platte), und ein Dienst, der wegen EINER Anfrage fuer alle weg ist,
+// ist der schlechtere Tausch.
+//
+// Laut wird es trotzdem: die Spur steht vollstaendig in der Konsole.
+process.on('uncaughtException', (err) => {
+    console.error('[unerwartet] uncaughtException — der Dienst laeuft weiter:', err)
+})
+process.on('unhandledRejection', (grund) => {
+    console.error('[unerwartet] unhandledRejection — der Dienst laeuft weiter:', grund)
+})
+
 // -------------------------------------------------------- Dateien ausliefern
 
 /** Liefert eine Datei aus, mit ETag und Bereichsanfragen.