docs: der Proxy konnte seit dem Aufraeumen nicht mehr schreiben

Beim Anlegen eines NPM-Benutzers kam "Internal Error". Im Container-Log stand
"attempt to write a readonly database" -- und der Prozess hielt einen Zeiger
auf /data/database.sqlite (deleted).

DAS WAR DAS AUFRAEUMEN NACH DEM VORFALL SELBST. Die Datenbank wurde am
12.08. um 22:11 per docker cp zurueckgeschrieben, und docker cp ERSETZT die
Datei statt sie zu ueberschreiben. Der seit dem 01.08. laufende Prozess zeigte
danach ins Leere. Rechte, Eigentuemer und Platz waren dabei alle in Ordnung --
die Meldung "readonly" fuehrt in die Irre.

Fuenfzehn Stunden unbemerkt, weil nur Schreibvorgaenge betroffen waren und
niemand welche ausloeste. Gekostet haette es ab dem 03.09. die
Zertifikatsverlaengerungen und ab dem 03.10. gueltige Zertifikate fuer proxy,
portainer und cdn -- ohne Meldung, ohne dass jemand etwas geaendert haette.

Behoben durch Neustart, 4 s Ausfall. Danach zeigt der Zeiger wieder richtig,
alle sechs Seiten antworten, der Benutzer liess sich anlegen.

Und der zweite Teil der Lehre steht auch dort: der Waechter haette das nicht
gefunden. Er zaehlt Ports und rechnet Pruefsummen, er versucht nirgends zu
schreiben.

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

docs/vorfall-2026-08-12-gitea.md

@@ -259,3 +259,67 @@ Datei zurueckgestellt      ->  "Wieder in Ordnung (Merker geleert)"
 Er prüft zuerst, ob er überhaupt etwas sehen kann, und meldet sonst
 „ungültig" statt „sauber" — die Lehre aus zwei Suchen, die genau das
 verwechselt haben.
+
+---
+
+## Nachtrag 13.08.2026 — ein Schaden aus dem Aufräumen selbst
+
+Beim Einrichten des Panels in `d4rk_gameserver` sollte ein Benutzer im Nginx
+Proxy Manager angelegt werden. Die Oberfläche antwortete mit **„Internal
+Error"**. Im Container-Log stand, was sie verschwieg:
+
+```
+insert into `user` ... - attempt to write a readonly database
+```
+
+**Der Nginx Proxy Manager konnte seit dem 12.08.2026, 22:11 Uhr, nichts mehr
+speichern.** Der letzte erfolgreiche Schreibvorgang war um 22:06 Uhr.
+
+### Die Ursache war das Aufräumen
+
+```
+lrwx------ 1 root root 64 Aug 11 16:04 18 -> /data/database.sqlite (deleted)
+```
+
+Der Prozess hielt einen Zeiger auf eine **gelöschte** Datei. Beim Aufräumen
+nach dem Vorfall wurde `/data/database.sqlite` per `docker cp` zurückgeschrieben
+— und `docker cp` **ersetzt** die Datei, statt sie zu überschreiben. Der seit
+dem 01.08. laufende Prozess zeigte danach ins Leere. SQLite meldet das als
+„readonly database", was in die Irre führt: Rechte, Eigentümer und Platz waren
+alle in Ordnung (root, 905 GB frei, Verzeichnis beschreibbar).
+
+### Was es fast gekostet hätte
+
+Nicht den Betrieb — Lesen ging weiter, alle Seiten liefen, fünfzehn Stunden
+lang fiel nichts auf. Aber:
+
+| Wann | Was |
+|---|---|
+| ab 03.09.2026 | Erste Zertifikatsverlängerung, wäre still gescheitert |
+| ab 03.10.2026 | `proxy`, `portainer` und `cdn` laufen in TLS-Warnungen |
+
+Ohne Meldung, ohne Eintrag, ohne dass jemand etwas geändert hätte.
+
+### Behoben
+
+Container neu gestartet, **4 Sekunden** Ausfall. Danach zeigt der Dateizeiger
+wieder auf die echte Datei, alle sechs Seiten antworten, und der Benutzer ließ
+sich anlegen. Die Datenbank liegt vorher als
+`database.sqlite.vor-neustart-2026-08-13` daneben.
+
+### Die Lehre
+
+**Eine Datei unter einem laufenden Dienst zu ersetzen ist etwas anderes, als
+sie zu überschreiben.** Richtig wäre gewesen:
+
+```sh
+docker exec <container> sh -c 'cat /pfad/neu > /data/database.sqlite'   # behält die Inode
+# oder
+docker cp neu <container>:/data/database.sqlite && docker restart <container>
+```
+
+Und der zweite Teil derselben Lehre: der Fehler war **fünfzehn Stunden lang
+unsichtbar**, weil nur Schreibvorgänge betroffen waren und niemand welche
+auslöste. Der Wächter in `tools/waechter.ps1` hätte ihn nicht gefunden — er
+zählt Ports und rechnet Prüfsummen, er versucht nirgends zu schreiben. Ob eine
+Schreibprobe je Dienst dazugehört, steht in `ROADMAP.md` als offene Frage.