feat(updater): support updates after verified SeaweedFS migration

docs/minio-umstellung-pilot.md

@@ -27,19 +27,20 @@ Die fachliche Abnahme erfolgt zusätzlich auf der konkreten Instanz.
   und die unveränderte Anwendung wieder starten.
 
 **Der Pilot ist noch kein neuer Standardinstaller und kein reguläres
-FEDEO-Release.** Der bisherige Anwendungs-Updater kennt nur MinIO. Seine Aufträge
-bleiben nach der Umstellung bewusst über `recoveryRequired` gesperrt, bis ein
-getesteter Provider-Adapter installiert wird. Diesen Zustand nicht mit dem alten
+FEDEO-Release.** Ältere Anwendungs-Updater kennen nur MinIO. Ihre Aufträge
+bleiben nach der Umstellung bewusst über `recoveryRequired` gesperrt. Dieser
+Entwicklungsstand enthält den SeaweedFS-Adapter und eine ausdrücklich geprüfte
+Übergabe über `adopt-updater` (unten). Diesen Zustand nicht mit dem alten
 `resolve` oder durch Löschen der Statusdatei aufheben. Ein alter Installer oder
 ein altes Release-Compose darf die umgestellte Installation nicht überschreiben.
 
 FEDEO 3.3.0 kann im Systemstatus weiterhin den MinIO-spezifischen Health-Endpunkt
 abfragen und dadurch den Dateispeicher als gestört anzeigen. Die tatsächliche
-Funktionsprüfung erfolgt im Pilot über signierte S3-Operationen. Herstellerneutrale
-Oberflächenchecks, eine Migrationskarte in der Oberfläche, automatische Updates
-auf SeaweedFS und der Standardinstaller sind nachfolgende Arbeitspakete.
-Wer diese Einschränkungen noch nicht im Betrieb tragen möchte, führt zunächst
-nur die Vorprüfung durch und bleibt mit der Instanz auf MinIO.
+Funktionsprüfung erfolgt im Pilot über signierte S3-Operationen. Dieser
+Entwicklungsstand prüft den angemeldeten S3-Bucket auch im Systemstatus; dafür
+ist anschließend ein Anwendungsrelease mit dieser Änderung erforderlich.
+Der Speicherwechsel selbst bleibt eine eigene betreute Hostaktion. Der bisherige
+Standardinstaller wird durch die Migration nicht ersetzt.
 
 ### Warum das Pilotimage eine gezielte Korrektur enthält
 
@@ -230,6 +231,47 @@ demselben Host anschließend auf das vorgesehene externe Backupziel übernehmen.
 MinIO-Daten, alte Container, Test-Restores und Offline-Images werden vom Pilot
 nicht automatisch gelöscht.
 
+## An den regulären Updater übergeben
+
+Erst nach `phase: complete`, erfolgreicher Anmeldung und fachlicher Prüfung eines
+bestehenden Dokuments ausführen. Die Übergabe stoppt keine FEDEO-Container:
+
+```sh
+sudo python3 pilot.py adopt-updater --directory /opt/fedeo
+sudo python3 /usr/local/lib/fedeo-updater/selfhost-update.py check --directory /opt/fedeo
+```
+
+Das neu erstellte Paket enthält die vier zusammengehörigen Updater-Dienstdateien
+mit Prüfsummen. `adopt-updater` installiert zuerst diesen Host-Dienst und ruft
+danach `adopt-storage` auf. Damit wird die alte Sperre erst nach Installation des
+passenden Updaters freigegeben. Bereits ausgegebene Pilotarchive bleiben unverändert;
+für eine schon umgestellte Instanz ein neues geprüftes Paket bereitstellen.
+**Dort nur `adopt-updater` ausführen, nicht erneut planen, kopieren oder aktivieren.**
+Für diese reine Übergabe ist kein erneutes Laden der Images erforderlich.
+
+Die Übernahme verlangt den abgeschlossenen Migrationszustand einschließlich
+Schreibfreigabe, vollständigem Kopiernachweis, erfolgreicher S3-Abnahmen und
+prüfsummengleicher Restore-Sicherung. Compose und `.env` müssen dem Pilotstand
+entsprechen. Sie prüft außerdem die tatsächlich laufenden Anwendungsimages,
+SeaweedFS-Image, lokale Mounts, Konfigurationsdateien und internen S3-Alias sowie
+das gestoppte und getrennte ursprüngliche MinIO. Ein aktueller Lesezugriff erfolgt
+mit dem installierten Backend-SDK. Fehler lassen die Updatesperre bestehen.
+
+Danach sind `check` und `apply` über den Host-Dienst und die bestehende Oberfläche
+möglich. Der erste Prüfplan benötigt keine pauschale Compose-Übernahmefreigabe.
+Der Adapter erhält SeaweedFS samt Konfiguration, Datenpfaden, Zugangsdaten und
+dem während der Migration festgehaltenen PostgreSQL-Image. Er entfernt die alten
+MinIO-Dienste aus dem heruntergeladenen Release-Compose, bevor Images geladen
+werden. Ein Anwendungsupdate lädt oder startet daher weder MinIO noch `mc`.
+Ein Wechsel der SeaweedFS- oder PostgreSQL-Version ist ein separater Vorgang.
+
+Vor jeder Datenbankschemamigration prüft das **Zielbackend-SDK** Schreiben,
+Lesen, MIME-Erhalt, Streaming, signierte Links, anonymen Zugriffsschutz und
+Löschen am aktiven Speicher. Ein Fehler hält die Anwendung angehalten und
+bewahrt den Wiederherstellungszustand. Die normale Anwendungsupdatesicherung
+enthält `storage/`, die Speicherbeschreibung und das exakte SeaweedFS-Image.
+Wiederherstellung und Grenzen stehen in [Selfhost-Updates](selfhost-updates.md).
+
 ## Nachgewiesene Tests und ausstehende Freigaben
 
 Der lokale S3-Test verwendet das offizielle MinIO-Release-Binary vom 7. September
@@ -249,7 +291,10 @@ Die Host-Integrationstests verwenden echte Speicher- und PostgreSQL-Container,
 aber künstliche Anwendungsprozesse. Rückkehr vor Schreibfreigabe sowie vollständige
 Umschaltung mit Restore und gesperrter Rückkehr nach Schreibfreigabe wurden erfolgreich
 durchlaufen. Die fachliche Abnahme von FEDEO auf der
-konkreten Instanz, ein physischer Hostneustart während jeder Phase, das reguläre
-Anwendungsupdate auf SeaweedFS und die vollständige Wiederherstellung auf einem
-anderen Host sind damit noch nicht nachgewiesen. Deshalb bleibt dieser Stand ein
+konkreten Instanz, ein physischer Hostneustart während jeder Phase und die
+vollständige Wiederherstellung auf einem anderen Host sind damit noch nicht
+nachgewiesen. Der zusätzliche Test `scripts/update/tests/host_storage_integration.py`
+prüft Migration, Updater-Übernahme, zwei Anwendungsupdates und Wiederherstellung
+aus einer regulären Updatesicherung mit echten Speicher-/Datenbankcontainern
+und künstlichen Anwendungsimages. Deshalb bleibt der Speicherwechsel ein
 betreuter Pilot; die allgemeinen Freigabekriterien des Konzepts gelten weiter.