Harden installer update activation fallback

Installation.md

@@ -55,7 +55,9 @@ Der Installer verändert eine bestehende Installation erst nach erfolgreicher Pa
 6. Die aktivierte EXE führt den Self-Test erneut aus.
 7. Erst danach werden Verknüpfungen und Windows-Uninstall-Eintrag aktualisiert.
 
-Bei einer Neuinstallation ohne bestehendes Ziel darf der Installer nach vollständig ausgeschöpften Move-Versuchen auf eine verifizierte Kopie zurückfallen. Dabei wird jede Datei aus dem bereits geprüften Staging nochmals gegen ihren Manifest-SHA-256 geprüft; anschließend läuft auch der zweite Self-Test aus dem endgültigen Ziel. Dieser Fallback gilt ausdrücklich nicht für Updates: Kann dort die Vorversion nicht atomar ins Backup verschoben werden, bricht das Update unverändert ab.
+Kann ausschließlich die Umbenennung des geprüften Staging-Verzeichnisses dauerhaft nicht ausgeführt werden, darf der Installer nach vollständig ausgeschöpften Move-Versuchen auf eine verifizierte Kopie zurückfallen. Dabei wird jede Datei aus dem Staging nochmals gegen ihren Manifest-SHA-256 geprüft; anschließend läuft auch der zweite Self-Test aus dem endgültigen Ziel. Bei einer Neuinstallation muss das Ziel noch fehlen. Bei einem Update ist der Fallback erst zulässig, nachdem die vollständige Vorversion atomar ins Backup verschoben wurde und das Ziel ebenfalls nicht mehr existiert. Er ist damit kein In-place-Update und überschreibt keine aktive Version.
+
+Scheitern Kopie, Hashprüfung oder Ziel-Self-Test, entfernt das Setup das teilweise neue Ziel und stellt beim Update das zuvor atomar erzeugte Backup wieder her. Kann bereits die Vorversion nicht atomar ins Backup verschoben werden, bleibt sie unverändert aktiv und das Update bricht ohne Kopierfallback ab.
 
 Schlägt ein Schritt nach Beginn der Umschaltung fehl, entfernt das Setup die neue Version und stellt das Backup wieder her. Tritt der Fehler bereits bei Paketprüfung oder Staging auf, meldet das Setup ausdrücklich **Kein Rollback erforderlich**, weil die aktive Installation unverändert blieb. Staging und Backup werden anschließend bestmöglich bereinigt. Kann ein nicht mehr benötigtes temporäres Verzeichnis wegen einer Dateisperre nicht gelöscht werden, bleibt die erfolgreiche Installation aktiv und das Log kennzeichnet den Abschluss als `success_with_temporary_cleanup_warning`.
 
@@ -77,7 +79,7 @@ Die Abschlussmeldung enthält einen stabilen Fehlercode und die betroffene Phase
 
 Das Log enthält Betriebssystem, Prozess-/OS-Bitness, .NET-Version, Rechner, Windows-Identität und Elevation sowie Installationspfade, freien Speicher, Dateigrößen, Versionen und SHA-256. Für Self-Tests werden Laufzeit, Exitcode dezimal und hexadezimal sowie vollständiges `stdout` und `stderr` geschrieben. Bei Fehlern folgen Exception-Kette, HRESULT und Stacktrace; jeder Rollbackschritt und sein Ergebnis werden separat protokolliert. Passwörter oder Verbindungsdaten werden vom Installer nicht verarbeitet oder geloggt.
 
-Bei einer gesperrten Verzeichnisverschiebung erscheinen `event=directory_move_retry` und nach einer Erholung `event=directory_move_recovered`. Eine Neuinstallation mit Kopierfallback protokolliert `event=activation_fallback_started`, `event=activation_fallback_complete` und im Abschluss `activation_method=verified_copy_fallback`. Ein dauerhaft gesperrtes Update verwendet keinen Kopierfallback und endet weiterhin mit `SETUP-ACTIVATION`, bevor die aktive Version verändert wurde.
+Bei einer gesperrten Verzeichnisverschiebung erscheinen `event=directory_move_retry` und nach einer Erholung `event=directory_move_recovered`. Ein Kopierfallback protokolliert `event=activation_fallback_started`, `event=activation_fallback_complete`, den Geltungsbereich `scope=new_install` oder `scope=update_after_backup` und im Abschluss `activation_method=verified_copy_fallback`. Kann bei einem Update bereits das Backup nicht erzeugt werden, endet es weiterhin mit `SETUP-ACTIVATION`, bevor die aktive Version verändert wurde.
 
 Für eine Supportanalyse bitte sichern:
 
@@ -89,7 +91,7 @@ Ein erfolgreicher Installer-Self-Test bestätigt Paket, Programmstart und lokale
 
 ## Emergency Restore nach einem Teilabbruch
 
-Version 2.2.2 kann einen Wiederanlauf allein aus einer erhaltenen `before.json` vorbereiten und ausführen. Eine mit Version 2.1.3 erzeugte Datei ist kompatibel; zusätzliche Plan- oder Nachher-Dateien des fehlgeschlagenen Laufs sind nicht erforderlich. Auch ein Fehler der GUI-Logweiterleitung ist vom fachlichen Executor isoliert und kann die späteren Planschritte nicht abbrechen.
+Version 2.2.3 kann einen Wiederanlauf allein aus einer erhaltenen `before.json` vorbereiten und ausführen. Eine mit Version 2.1.3 erzeugte Datei ist kompatibel; zusätzliche Plan- oder Nachher-Dateien des fehlgeschlagenen Laufs sind nicht erforderlich. Auch ein Fehler der GUI-Logweiterleitung ist vom fachlichen Executor isoliert und kann die späteren Planschritte nicht abbrechen.
 
 1. Die erhaltene `before.json` außerhalb des Arbeitsverzeichnisses zusätzlich sichern.
 2. Anwendung als Administrator starten und denselben Zielserver wählen, der im Snapshot gespeichert ist.