Harden installer update activation fallback

Dokumentation.md

@@ -161,7 +161,7 @@ Die Aktivierung ist transaktional aufgebaut:
 
 Fehler vor der ersten Mutation werden als **Kein Rollback erforderlich** ausgewiesen. Ein Rollback wird nur als erfolgreich bezeichnet, wenn seine einzelnen Schritte ohne Fehler abgeschlossen wurden; ein verbliebenes Backup ohne aktives Programmverzeichnis verletzt eine zusätzlich geprüfte Invariante und wird als unvollständiger Rollback gemeldet. Bereinigungsprobleme an einem nicht mehr benötigten Backup oder Deinstallations-Quarantäneverzeichnis werden als erfolgreiche Operation mit Warnung protokolliert und zerstören die wiederherstellbaren Dateien nicht blind.
 
-Wenn ausschließlich die atomare Staging-Umbenennung einer Neuinstallation dauerhaft gesperrt bleibt, ist ein eng begrenzter Kopierfallback zulässig: Es existiert dabei keine aktive Vorversion, jede Zieldatei wird erneut anhand des Manifests per SHA-256 geprüft und der zweite Self-Test läuft weiterhin aus dem endgültigen Ziel. Updates verwenden diesen Fallback absichtlich nicht, weil die unveränderte alte Installation Vorrang vor einer nicht atomaren In-place-Aktualisierung hat. Jeder Retry und die verwendete Aktivierungsmethode stehen im Setup-Log.
+Wenn ausschließlich die atomare Staging-Umbenennung dauerhaft gesperrt bleibt, ist ein eng begrenzter Kopierfallback zulässig: Bei einer Neuinstallation muss das Ziel fehlen; bei einem Update muss die vollständige Vorversion bereits atomar ins Backup verschoben worden sein und das aktive Ziel fehlen. Jede Zieldatei wird erneut anhand des Manifests per SHA-256 geprüft, und der zweite Self-Test läuft weiterhin aus dem endgültigen Ziel. Der Fallback ist nie ein In-place-Update. Ein Teilfehler entfernt die Zielkopie und stellt beim Update das Backup wieder her. Jeder Retry, der Geltungsbereich und die verwendete Aktivierungsmethode stehen im Setup-Log.
 
 Das dauerhafte Setup-Log enthält pro Lauf einen Kontextkopf mit Version, Betriebssystem, 32-/64-Bit-Kontext, CLR, Rechner, Identität und Elevation. Hinzu kommen Pfade, freier Speicher, Dateiversion/-größe/-SHA-256, vollständige Self-Test-Ausgaben mit Exitcode, Exception-Ketten mit HRESULT und Stacktrace sowie jeder Rollbackschritt. Stabile `SETUP-*`- und `UNINSTALL-*`-Fehlercodes ermöglichen die Zuordnung unabhängig vom lokalisierten Meldungstext. Die Aufbewahrung beträgt 90 Tage. Wenn ProgramData für die Diagnose nicht verfügbar ist, wird ein Temp-Fallback verwendet und sichtbar gemeldet; die Schaltfläche **Diagnoselogs öffnen** öffnet den regulären Ablageort.
 
@@ -182,7 +182,8 @@ Das äußere ZIP erhält zusätzlich eine SHA-256-Datei und eine Certutil-kompat
 - Staging-Fehler ohne Mutation einer bestehenden Installation.
 - Erfolgreiche Staging-Aktivierung.
 - Erholung nach einer vorübergehenden Rename-Sperre mit korrektem Backoff und Diagnoseereignissen.
-- Verifizierter Kopierfallback einer dauerhaft move-gesperrten Neuinstallation.
+- Verifizierter Kopierfallback einer dauerhaft move-gesperrten Neuinstallation und eines bereits atomar gesicherten Updates.
+- Vollständiger Update-Rollback, wenn der Ziel-Self-Test nach dem Kopierfallback fehlschlägt.
 - Begrenzter Abbruch eines dauerhaft move-gesperrten Updates ohne Veränderung der Vorversion.
 - Wiederherstellung der Vorversion, wenn der Self-Test nach Aktivierung fehlschlägt.
 - Deinstallation durch atomare Umbenennung des Programmverzeichnisses vor der bestmöglichen Bereinigung.