docs: Richtigstellung -- der Auto-Deploy funktioniert, ich war zu ungeduldig

Zwei falsche Diagnosen hintereinander, beide aus einem Zwischenstand
geschlossen, waehrend der Vorgang noch lief. Was wirklich passiert ist:

    12:48:18   Push 93156e5
    12:48      Portainer hat die Dateien im Stack-Verzeichnis
    12:57      hier gemessen: Abbild 15 h alt, Container von gestern
               -> daraus "er baut nicht" geschlossen. FALSCH.
    13:01:02   Abbild neu gebaut
    13:01:14   Container neu gestartet
    13:02      pruefeSicherung im Container: 2, melden.js da, Panel HTTP 200

Zwischen Push und laufendem neuen Code liegen rund DREIZEHN MINUTEN -- Portainer
fragt in Intervallen nach, nicht sofort. Die Messung um 12:57 fiel mitten in
dieses Fenster: die Dateien waren schon da, das Abbild noch nicht neu. Aus dem
Schnappschuss habe ich einen Systemfehler gemacht.

Das ist genau der Fehler, gegen den der Bericht geschrieben ist -- eine
plausible Erklaerung, die zum Schnappschuss passt, behauptet, bevor der Vorgang
zu Ende war.

pull_policy: build bleibt drin, aber NICHT mehr aus dem Grund im Commit davor.
Es repariert nichts; es macht das Neubauen nur ausdruecklich, damit ein
handgetipptes `docker compose up -d` dasselbe tut wie die Automatik. Folgenlos
entfernbar.

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

docs/befunde-2026-08-12.md

@@ -296,7 +296,7 @@ Setup → Einstellungen, und der Zweig läuft.
 
 ---
 
-## ⚠️ Nachtrag: der Auto-Deploy hat nicht ausgelöst
+## ~~Nachtrag: der Auto-Deploy hat nicht ausgelöst~~ — zwei falsche Diagnosen, siehe unten
 
 `docs/auto-deploy.md` beschreibt zwei Wege — Portainer-Webhook oder Gitea
 Actions. **Am 12.08.2026 hat keiner von beiden gegriffen.** Gemessen nach dem
@@ -348,3 +348,41 @@ Auto-Deploy von allein.
 Das ist keine Kleinigkeit für die Zukunft: ein Deploy, von dem man glaubt, dass
 er automatisch läuft, ist schlimmer als gar keiner. Man pusht, hakt es ab, und
 der Fehler, den man gerade behoben hat, läuft weiter.
+
+### Richtigstellung: der Auto-Deploy funktioniert. Er ist nur langsamer als meine Geduld
+
+**Der Abschnitt oben war falsch, und zwar zweimal.** Erst hieß es „kein Runner,
+also läuft gar nichts", dann „er zieht, aber er baut nicht". Beides war aus
+einem Zwischenstand geschlossen, während der Vorgang noch lief.
+
+Was wirklich passiert ist:
+
+```
+12:48:18   Push 93156e5
+12:48      Portainer hat die Dateien im Stack-Verzeichnis
+12:57      hier gemessen: Abbild 15 h alt, Container von gestern
+           -> daraus "er baut nicht" geschlossen. FALSCH.
+13:01:02   Abbild neu gebaut
+13:01:14   Container neu gestartet
+13:02      pruefeSicherung im Container: 2 · melden.js: da · Panel: HTTP 200
+```
+
+Zwischen Push und laufendem neuen Code liegen **rund dreizehn Minuten** —
+Portainer fragt in Intervallen nach, nicht sofort. Meine Messung um 12:57 fiel
+mitten in dieses Fenster: die Dateien waren schon da, das Abbild noch nicht neu.
+Aus diesem Schnappschuss habe ich einen Systemfehler gemacht.
+
+**Das ist genau der Fehler, gegen den dieser Bericht geschrieben ist** — eine
+plausible Erklärung, die zum Schnappschuss passt, behauptet, bevor der Vorgang
+zu Ende war. Der Unterschied zu den anderen Befunden hier: bei denen wurde
+gewartet, bis etwas fertig war.
+
+### Was mit `pull_policy: build` passiert
+
+Die Zeile steht weiter in `docker-compose.yml`, aber **nicht mehr aus dem Grund,
+der im Commit davor stand**. Sie repariert nichts — Portainer baut auch ohne sie
+neu. Sie macht es nur ausdrücklich: bei einem Stack mit `build:` ist „immer neu
+bauen" das, was man beim Ausrollen will, und wer später von Hand
+`docker compose up -d` tippt, bekommt dann dasselbe Ergebnis wie die Automatik.
+
+Wer sie nicht will, kann sie folgenlos entfernen.