feat: add tested dependency updates with runtime rollback

Documentation.md

@@ -224,3 +224,70 @@ Peppol, DATEV-API und automatischer Postfacheingang. Diese Fälle nicht durch bl
 Freitexthinweise nachbilden. Das vorhandene CII-XML ist keine XRechnung, auch wenn
 beide Formate EN16931 verwenden. Aufbewahrung/Backups und fachliche Freigabe müssen
 in den betrieblichen Ablauf eingebunden werden.
+
+
+## Updates und Rollback
+
+Der empfohlene Update-Einstieg für diesen Linux-Checkout ist
+`python3 scripts/update.py` (nur Standardbibliothek, unabhängig von der venv).
+Alternativ: `./bin/einvoice --update`. Mit `--apply` aktivieren, mit `--status`
+den aktiven/vorherigen Stand anzeigen, mit `--rollback` zurückwechseln.
+`--mustang-version 2.26.0` erlaubt eine gezielte stabile Mustang-Version.
+Ohne Versionsvorgabe wird Maven `release` bevorzugt; Vorabversionen werden abgewiesen.
+
+1. Exklusive Dateisperre verhindert gleichzeitige Wartungsläufe.
+2. Neue venv unter `.runtime/releases/<Zeit-ID>/venv` erstellen und Projekt als
+   Wheel installieren, einschließlich PDF-Extra und transitiver Abhängigkeiten.
+   `pyproject.toml` ist die maßgebliche Abhängigkeitsdefinition. pip wählt die
+   neuesten zum Interpreter und zu diesen Vorgaben passenden Versionen.
+3. Mustang von Maven herunterladen und veröffentlichte SHA1-Prüfsumme vergleichen.
+   Das prüft Übertragungsfehler, ist keine unabhängige Signaturprüfung.
+4. Versionen vergleichen und Installationsbericht, vollständigen Paketstand
+   (`requirements.freeze.txt`) sowie Manifest mit Quell-Commit und JAR-SHA256 speichern.
+5. `pip check`, WeasyPrint-PDF, beide CLI-Hilfen und alle Unittests einschließlich
+   echter Integrationstests ausführen. Dazu gehören PDF/A, eingebettetes XML,
+   EML-Anhang, neuer/bekannter Kunde sowie Ablehnung falscher Summen, Einheiten und
+   PDFs ohne Rechnungs-XML. Tests nutzen temporäre Muster-/Kundendaten.
+   `-I` und ein fremdes Arbeitsverzeichnis verhindern, dass der Checkout die
+   tatsächlich installierte Anwendung bei den Tests verdeckt.
+6. Nur bei `--apply`: bisherigen Stand sichern und `.runtime/current` atomar auf
+   den Kandidaten setzen. Dieselben Healthchecks nach der Aktivierung wiederholen;
+   bei Fehler/KeyboardInterrupt sofort den bisherigen Zeiger wiederherstellen.
+
+`bin/einvoice` und `bin/jr-einvoice` lösen den Zeiger pro Aufruf einmal auf und
+verwenden Python und Mustang aus demselben Release. Nutzerablage bleibt standardmäßig
+`private/` im Checkout, auch bei Wheel-Installation; `JR_EINVOICE_HOME` und
+`JR_EINVOICE_PRESETS` werden respektiert. Vor dem ersten verwalteten Update nutzen
+die Starter `.venv`; beim ersten Aktivieren wird diese unverändert verlinkt und die
+bisherige Mustang-JAR kopiert. Diese erste Baseline ist noch die ursprüngliche
+Entwicklerumgebung: nicht löschen/verändern, wenn sie als Rückfall benötigt wird.
+Spätere Releases sind eigenständige, fest installierte Wheel-Umgebungen.
+
+Fehlende Downloads, defekte Prüfsummen, Resolverfehler, Timeouts und fehlgeschlagene
+Tests führen zu Exitcode 1. Erfolgreiche Wartung liefert 0. Kandidaten, vorherige
+Releases und Logs bleiben zur Diagnose erhalten; es gibt kein automatisches Löschen.
+Nach Abbruch durch SIGKILL/Stromausfall zeigt `current` auf einen vollständigen
+vorherigen oder neuen Stand; eine noch ausstehende Nachprüfung wird nicht automatisch
+nachgeholt. Bei Bedarf `--rollback` ausführen. Rollback prüft den Zielstand vorab;
+ist er wegen externer Änderungen defekt, bleibt der aktuelle Zeiger erhalten.
+
+Updates ändern keine Rechnungen, Kunden oder Rechnungsnummern. Rollback umfasst
+Python-Pakete, den installierten Anwendungscode und Mustang; keine Git-Änderungen,
+privaten Daten, Python-Systemversion, Java oder nativen Bibliotheken. Nach Systemupdates
+muss eine bisherige venv ggf. neu aufgebaut werden. Systemupdates auf Arch als
+vollständiges Update über `sudo pacman -Syu` durchführen und danach den Prüflauf
+starten. Der Updater führt weder sudo noch Systempaketänderungen aus.
+
+Es gibt bewusst keinen Hintergrundtimer: neue Stände werden explizit geprüft und
+übernommen. Zum Beispiel vor dem nächsten Rechnungslauf oder monatlich prüfen.
+Neue Projektversionen zunächst separat über Git holen, danach den Updater starten;
+der Updater führt kein `git pull` aus. Uncommittete Quellen werden mit eingebaut,
+der Manifest-Commit allein beschreibt diese daher nicht vollständig. Die bisherigen
+`setup-mustang`/`mustang-update --apply` sind einfache Direktinstallationen ohne
+Transaktionsschutz und verwalten die neue Laufzeit nicht; für Updates den gemeinsamen
+Ablauf verwenden. Eine Wheel-Installation außerhalb des Checkouts besitzt diesen
+Checkout-Updater nicht.
+
+Technische Grundlagen: [pip Versionsauflösung und Installationsbericht](https://pip.pypa.io/en/stable/cli/pip_install/),
+[Python venv und feste Umgebungspfade](https://docs.python.org/3/library/venv.html).
+Umgebungen bleiben deshalb an ihrem Erstellungsort; nur der Zeiger wird gewechselt.