Show periodic rclone progress and remote verification phases

UPDATE_ANLEITUNG.md

@@ -354,6 +354,46 @@ und die Dienstzustände prüfen; insbesondere ein Stop-Timeout ist kein Nachweis
 für eine erfolgreiche Wiederaufnahme. Die Änderung wirkt für neue Aufträge,
 nicht nachträglich für einen bereits gestarteten alten Worker.
 
+## OneDrive: HTTP 409 resourceModified und stilles Journal
+
+Der Lauf auf Gemini vom 10.09.2026 ab 15:30 Uhr hat die geschützte Kopierphase
+und Dienstwiederaufnahme erfolgreich abgeschlossen. Um 15:46:11 meldete rclone
+1.74.3 bei `wordpress.tar.zst` HTTP 409 `resourceModified`; das deutet auf einen
+Versions-/eTag-Konflikt am OneDrive-Objekt. Der konkrete Auslöser ist anhand
+dieser Meldung nicht bestimmt. Der lokale Satz bleibt erhalten; eine erfolgreiche
+Offsite-Abnahme ist damit noch nicht belegt.
+
+HTTP 409 ist in dieser rclone-Version nicht in der allgemeinen Liste unmittelbar
+wiederholter OneDrive-HTTP-Fehler enthalten. `--low-level-retries 20` bedeutet daher
+nicht, dass genau dieser Fehler sofort 20-mal versucht wird. Die standardmäßig
+bis zu sechs Versuche über `--retries` betreffen den übergeordneten Kopierauftrag;
+andere Dateiübertragungen können vor dessen Wiederholung noch laufen. Bei als
+fatal oder nicht wiederholbar eingestuften Fehlern kann rclone früher abbrechen.
+Quelle: [rclone 1.74.3 OneDrive-Code](https://github.com/rclone/rclone/blob/v1.74.3/backend/onedrive/onedrive.go),
+[Wiederholungen](https://rclone.org/docs/#retries-int).
+
+Die bisherigen Aufträge zeigten normale Fortschrittsstatistiken nicht an:
+rclone meldet sie standardmäßig auf INFO, die normale Logschwelle ist NOTICE.
+Das aktuelle Paket setzt `--stats-log-level NOTICE --stats-one-line` mit
+`RCLONE_STATS_INTERVAL="1m"` und meldet die Phasen Upload, Rücklesen und
+Freigabe des Abschlussmarkers. Statistiken gehen nach stderr, damit maschinell
+gelesene Marker und Dateilisten auf stdout unverändert bleiben.
+Quelle: [rclone-Statistiken](https://rclone.org/docs/#stats-log-level-loglevel).
+
+`RCLONE_TIMEOUT="1h"` ist die bestehende I/O-Leerlauffrist, keine Gesamtlaufzeit
+und kein Versprechen einer Meldung pro Minute. `RUNNING` und der systemd-Zustand
+`activating/start` bei der oneshot-Unit belegen keinen Datenfortschritt. Bei einem
+stillen alten Auftrag Prozesszustand und TCP-Zähler mit `ps`/`ss` prüfen;
+steigende Zähler belegen Netzwerkverkehr, aber noch keinen erfolgreichen Upload.
+Quelle: [I/O-Leerlauffrist](https://rclone.org/docs/#timeout-duration).
+
+Eine neue Paketdatei oder geänderte Config ergänzt keine Statistiken im bereits
+laufenden rclone-Prozess. Keinen zweiten Upload parallel starten und den
+vorhandenen lokalen Satz nicht löschen. Ein einzelner 409-Fehler begründet keine
+Abschwächung der Prüfungen durch `--ignore-existing`/`--size-only`.
+Entscheidend bleiben erfolgreiches Rücklesen,
+Manifest-/Archivprüfung und `SUCCESS` in der Ergebnisdatei des konkreten Auftrags.
+
 ## Paket reproduzieren
 
 Aus einem sauberen, eingecheckten Repository:
@@ -371,6 +411,8 @@ Das ausführbare Paket ausschließlich über euren vertrauenswürdigen Kanal bez
 ## Verifikation der Lieferung
 
 52 Testfälle erfolgreich: vollständiger Durchlauf mit 50 Tests, anschließend die zwei zusätzlichen Abbruchtests für Kopie und Upload. ShellCheck und Shell-Syntaxprüfung abschließend erfolgreich.
+Für die danach ergänzten Upload-Statistiken bestanden drei gezielt wiederholte Tests: gedrosselter echter Crypt-Upload mit Remote-Restore, fehlgeschlagene Rückleseprüfung ohne Abschlussmarker und TERM während des Uploads. ShellCheck und Shell-Syntax bestanden erneut; kein erneuter vollständiger Durchlauf für diese Protokollergänzung.
+
 Die Tests enthalten echte MariaDB-Dumps/Imports und lokale rclone-Crypt-Roundtrips;
 systemd/occ und die systemd-run-Übergabe sind simuliert. Das Übergabemodell
 berücksichtigt jetzt das Warten auf den oneshot-Startauftrag: Der Regressionstest