Fix crash handling and log noise in logging feature

Review of the logging work from the previous commit turned up a real
correctness issue: the uncaughtException/unhandledRejection handlers
logged the error but let the process keep running, which silently
disabled Node's default crash-on-fatal-error behavior and could leave
a zombie process serving broken requests instead of restarting. Both
processes now log and then exit(1); restart: unless-stopped is added
to both services so Docker actually brings them back up.

Also: harden the logger against JSON.stringify throwing on
non-serializable meta, log aborted (closed-before-finished) requests
in the API access log, and stop the Next.js proxy from logging the
Docker healthcheck's request to "/" every few seconds so real
navigation events aren't drowned out.

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

docs/deployment.md

@@ -58,6 +58,15 @@ mit Laufzeit und Speicherverbrauch – nützlich, um Speicherlecks oder Hänger
 einem 502 über einen längeren Zeitraum nachzuvollziehen. Für die Detailsuche
 `LOG_LEVEL=debug` setzen; das protokolliert zusätzlich den Start jeder
 API-Anfrage und macht damit hängende (nie abgeschlossene) Requests sichtbar.
+Ein `close`-Ereignis ohne vorheriges `finish` wird als `request aborted before
+response finished` (`warn`) geloggt und zeigt damit vom Client oder einem
+vorgeschalteten Proxy abgebrochene Verbindungen.
+
+Eine unbehandelte Exception oder Promise-Rejection wird geloggt und beendet
+den jeweiligen Prozess anschließend bewusst (`process.exit(1)`), statt in
+einem unbekannten Zustand weiterzulaufen. Beide Dienste laufen deshalb mit
+`restart: unless-stopped`, damit Docker sie danach automatisch neu startet;
+ohne diese Policy würde ein Crash den Dienst dauerhaft unerreichbar lassen.
 
 ## Voraussetzungen für ein späteres Produktionssetup