Keep old pages readable, detect stale settings writes, make backups honest

- Own CSS is parsed on write only. A page whose stored CSS no longer
  passes a stricter rule answers 200 and opens in the editor; that one
  block loses its CSS. A document read several times in one request is
  validated once.
- Settings and theme refuse a write from an outdated form.
- A backup fails when a media file does not arrive completely and
  leaves no half directory behind; rotation counts intact backups only.
- The archive update takes its backup behind the maintenance page.
- A package import puts all media in place before removing the old
  ones, reports honestly when that fails and keeps a maintenance state
  that was already on.
- Restoring replaces the SQLite file in one move and points at pending
  migrations.
- Six irreversible actions ask first, in a dialog of the admin's own.
- Ctrl+S in the editor takes the field being typed in along; Delete
  no longer removes a block while a dialog is open.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -1,6 +1,14 @@
 # Architekturentscheidungen
 
-Stand: 27.10.2026. Arbeitstitel KantSites; Produktname offen.
+Stand: 10.11.2026. Arbeitstitel KantSites; Produktname offen.
+
+## ADR 128 – Lesen ist nachsichtig, Schreiben streng; Kennung statt Versionsspalte (10.11.2026)
+
+**Kontext:** Die Komplettanalyse vom 10.11.2026 fand drei Stellen, an denen ein gespeicherter Stand zur Falle wurde: Seiten wurden bei jedem Lesen voll geprüft, samt eigenem CSS – eine später verschärfte Regel ließ sie mit 500 antworten und im Editor nicht mehr öffnen; Einstellungen und Design überschrieb der zweite von zwei Admins still; Sicherungen galten als unversehrt, auch wenn Mediendateien fehlten.
+
+**Entscheidung:** (1) `DocumentValidator` parst eigenes CSS nur noch beim Schreiben. Beim Lesen bleibt die Strukturprüfung, das CSS eines Blocks fällt in `compileCss()` weg, wenn es nicht mehr gilt – wie ADR 116 es für Bereiche schon vorsah. Ein beim Lesen geprüftes Dokument wird je Anfrage über seinen Inhalt gemerkt und nicht noch einmal geprüft. (2) `SiteSettings::stamp()` und `Theme::stamp()` liefern einen Hash des gespeicherten JSON; die Formulare tragen ihn als `expected`, `save()` vergleicht in derselben Transaktion und wirft `StaleWrite`. (3) `Backup::create()` wirft, wenn eine Mediendatei nicht vollständig ankommt, und räumt den angefangenen Ordner weg; `intact()` zählt die Mediendateien; `rotate()` zählt nur unversehrte Sicherungen und entfernt beschädigte nach einer Stunde.
+
+**Folgen:** Keine Migration: Die Kennung ist ein Hash, keine Spalte. Ein Formular ohne `expected` (aus einem vor dem Update geladenen Bildschirm, aus Tests, aus dem Installer) speichert ungeprüft wie bisher. Eigene Skripte werden weiter auch beim Lesen geprüft. Eine Sicherung scheitert jetzt hörbar, wo sie vorher unvollständig gelang – bei vollem Speicher gibt es dann keine neue, aber die alten vollständigen bleiben. Nicht umgesetzt: der MySQL-Rückweg nach einem zurückgerollten Update (neu angelegte Tabellen bleiben stehen); alle Installationen laufen auf SQLite.
 
 ## ADR 127 – Plugins mit eigenem PHP-Code, wie bei WordPress (09.11.2026)
 

docs/UPDATE.md

@@ -69,10 +69,10 @@ Alles bis hierhin setzt eine Git-Arbeitskopie voraus. Auf geteiltem Hosting gibt
 Der Ablauf ist derselbe wie oben, nur ohne `git`:
 
 1. **Fassung ermitteln.** Die Releaseliste nennt den neuesten Tag. Antwortet sie nicht – viele Hoster lassen keine ausgehenden Verbindungen zu –, endet es hier, und es wurde nichts angefasst.
-2. **Sichern.** Datenbank und Medien nach `var/backups/`, vor dem ersten Handgriff.
-3. **Archiv laden und Prüfsumme vergleichen.** Stimmt sie nicht, wird nicht entpackt. Die Adresse steht in der Konfiguration, nicht in der Anfrage.
-4. **Entpacken und auf Vollständigkeit prüfen.** Fehlen `VERSION` oder `vendor/`, ist es kein brauchbares Release – und das fällt auf, bevor der Wartungszustand angeht.
-5. **Wartungszustand an, Dateien ersetzen.** `bin`, `config`, `migrations`, `src`, `templates`, `vendor`, `composer.json`, `composer.lock`, `migrations.php`, `cli-config.php`, `VERSION`. Der alte Stand wandert nach `var/update/<zeitstempel>/alt/`, er wird nicht gelöscht.
+2. **Archiv laden und Prüfsumme vergleichen.** Stimmt sie nicht, wird nicht entpackt. Die Adresse steht in der Konfiguration, nicht in der Anfrage.
+3. **Entpacken und auf Vollständigkeit prüfen.** Fehlen `VERSION` oder `vendor/`, ist es kein brauchbares Release – und das fällt auf, bevor der Wartungszustand angeht.
+4. **Wartungszustand an, dann sichern.** Datenbank und Medien nach `var/backups/`. Seit 1.41.0 hinter der Wartungsseite: Vorher entstand die Sicherung vor dem Laden, und was in dieser Zeit noch hereinkam, fehlte nach einem Zurückschalten. Scheitert die Sicherung – auch an einer einzelnen Mediendatei –, geht die Wartung wieder aus und nichts wird ersetzt.
+5. **Dateien ersetzen.** `bin`, `config`, `migrations`, `src`, `templates`, `vendor`, `composer.json`, `composer.lock`, `migrations.php`, `cli-config.php`, `VERSION`. Der alte Stand wandert nach `var/update/<zeitstempel>/alt/`, er wird nicht gelöscht.
 6. **`public/` wird zusammengeführt, nicht ersetzt.** Dort liegen Dateien der Anwendung und Dateien des Betreibers nebeneinander: `assets/fonts` (hochgeladene Schriften) und `assets/build` (das erzeugte Stylesheet-Bündel) bleiben unangetastet.
 7. **Zwischenspeicher leeren.**
 8. **Zweiter Knopf: Migrationen.** Sie laufen in einer **eigenen Anfrage**, weil ein PHP-Prozess, der sich selbst ausgetauscht hat, mit den Klassen weiterarbeitet, die er beim Start geladen hat. Erst danach geht der Wartungszustand aus.