Protect writer stop jobs from competing healthcheck requests

UPDATE_ANLEITUNG.md

@@ -1,5 +1,50 @@
 # Automatisches Update-Paket
 
+## Nachtrag vom 15.09.2026: Healthcheck verdrängt Apache-Stop
+
+Im Update mit Paket `3d16f33f24c0` wurde die alte Sicherung vom 12.09. um
+14:29:24 MESZ im dritten Rückleseversuch vollständig bestätigt (16 Dateien,
+keine Unterschiede). Erst danach entfernte die Platzbereinigung ihre lokale
+Kopie. Die neue Installation und ihre Vorprüfung waren erfolgreich.
+
+Der anschließende Abnahmelauf `appbackup_2026-09-15_12-29-36_75975f52` brach
+bereits beim Anhalten der Writer ab: Um 14:29:56 stoppte das Backup `httpd`;
+um 14:30:00 meldete `ai-rem-healthcheck.service` einen fehlgeschlagenen öffentlichen
+Healthcheck und veranlasste einen Apache-Reload. Dieser verdrängte den laufenden
+Stop-Auftrag (`Job for httpd.service canceled`). Ein neues Backup oder dessen
+Restore-Test wurde in diesem Lauf noch nicht fertiggestellt. Die Fehlerbereinigung
+schaltete den Nextcloud-Wartungsmodus aus und startete Apache und Cron wieder.
+Backup- und Restore-Test-Timer blieben wegen der fehlenden Abnahme gestoppt.
+
+Die Korrektur schützt jeden Writer-Stop mit
+`systemctl stop UNIT --job-mode=replace-irreversibly`. Die vorhandene
+`ConditionPathExists` verhindert Starts während der Kopie, schützt aber allein
+keinen noch laufenden Stop-Auftrag gegen einen Reload. Der zusätzliche Jobmodus
+verhindert dessen Verdrängung, solange der Stop läuft. Er setzt keine dauerhafte
+Maskierung, ändert keine Stop-Zeitlimits und verhindert den normalen Wiederanlauf
+nach Freigabe der Startsperren nicht. Ein explizites `systemctl cancel` oder ein
+echter Stopfehler bleibt ein Abbruchgrund. Siehe die
+[systemd-Dokumentation zum Jobmodus](https://github.com/systemd/systemd/blob/v257/man/systemctl.xml).
+
+Ein Regressionstest gegen echten Benutzer-systemd reproduziert den alten
+Reload-Konflikt trotz gesetzter Startbedingung und prüft den korrigierten Stop
+gegen Reload und Start. Die Container-Tests prüfen weiterhin die Wiederaufnahme
+nach Stopfehlern und die Konsistenzsperren während der Kopie.
+
+Lokale Verifikation am 15.09.2026: 119 Fälle im Container-Standardlauf, davon
+111 erfolgreich und acht planmäßig übersprungen (fünf separate
+Docker-Integrationstests und drei Benutzer-systemd-Tests); Laufzeit 906,3 Sekunden.
+Die drei Benutzer-systemd-Tests bestanden separat und prüfen auch den inaktiven
+Dienstzustand nach dem geschützten Stop. ShellCheck und Shell-Syntaxprüfung
+bestanden. Die Serverabnahme dieser Korrektur steht noch aus.
+
+Das neue Paket wie unten per SCP übertragen und normal starten; ein vorheriger
+Rollback ist nicht erforderlich. Der Healthcheck muss für diese Korrektur nicht
+dauerhaft abgeschaltet werden. Der Installer erstellt erneut ein Abnahmebackup
+und führt den vollständigen Restore-Test aus. Erst `SUCCESS` in seiner neuen
+`result.txt` bestätigt den Abschluss und die Timer-Aktivierung. Diese Korrektur
+betrifft den Dienststopp; die ursprüngliche OneDrive-Ursache bleibt ungeklärt.
+
 ## Nachtrag vom 15.09.2026: Restore-Abnahme nach erfolgreichem Backup
 
 Das Paket `4f220dbc6447` bestand auf Gemini das neue Backup einschließlich