feat: establish secure update foundation

AGENTS.md

@@ -44,13 +44,18 @@ Ersetze die bisherige Version mindestens an diesen Stellen:
 
 - `compose.yml`
 - Image-Beispiel in `README.md`
+- Versionshinweis in `UPDATE.md`
+- `ARG VERSION` in `Dockerfile`
+- Fallback-Version in `internal/buildinfo/version.go`
 
-Danach dürfen diese Dateien die vorherige Version nicht mehr enthalten. Setze `PREVIOUS` auf die tatsächlich vorherige Version:
+`MINIMUM_UPDATE_VERSION`, `MinimumUpdateVersion`, `MinimumAgentVersion` und die Vertragsnummern sind Kompatibilitätsgrenzen. Ändere sie nicht bei normalen Releases, sondern nur bei einem bewusst geplanten Vertragsbruch mit passender Migration und Dokumentation.
+
+Danach dürfen die gepinnten Image-Referenzen nicht mehr auf die vorherige Version zeigen. Historische Hinweise zur v1.4-Update-Basis bleiben bestehen. Setze `PREVIOUS` auf die tatsächlich vorherige Version:
 
 ```bash
 PREVIOUS=v1.2.1
-if grep -n "$PREVIOUS" README.md compose.yml; then
-  echo "Alte Version $PREVIOUS ist noch eingetragen." >&2
+if grep -n "domain-control-webinterface-prod:$PREVIOUS" README.md compose.yml; then
+  echo "Alte Image-Version $PREVIOUS ist noch eingetragen." >&2
   exit 1
 fi
 docker compose -f compose.yml config --quiet
@@ -133,13 +138,13 @@ git ls-remote origin refs/heads/main refs/tags/vX.Y.Z 'refs/tags/vX.Y.Z^{}'
 
 ## 5. Container-Image veröffentlichen
 
-Ein `v*`-Tag startet den Gitea-Workflow. Prüfe zuerst in Gitea, ob der Run tatsächlich läuft und erfolgreich endet. Wenn der Workflow erfolgreich ist, darf nicht zusätzlich manuell in dieselben Tags gepusht werden.
+Wenn Repository-Actions aktiviert sind, startet ein `v*`-Tag den Gitea-Workflow. Prüfe dann zuerst in Gitea, ob der Run tatsächlich läuft und erfolgreich endet. Wenn der Workflow erfolgreich ist, darf nicht zusätzlich manuell in dieselben Tags gepusht werden. Sind Repository-Actions deaktiviert, verwende ausschließlich den manuellen Multi-Arch-Fallback.
 
 ### Bekannter Gitea-Runner-Zustand
 
-Stand 13.07.2026 ist kein Gitea-Actions-Runner aktiv. Die Runs bleiben auf `queued`. Der übliche Cancel-Endpunkt ist in dieser Gitea-Version nicht vorhanden; das Löschen wartender Runs antwortete mit HTTP 400. Verändere deshalb nicht direkt die Gitea-Datenbank. Prüfe den Zustand bei jedem Release neu.
+Stand 29.08.2026 ist kein Gitea-Actions-Runner aktiv. Repository-Actions sind deshalb deaktiviert. Run 7 für `v1.3.0` liegt weiterhin intern auf `queued`, kann im deaktivierten Zustand aber nicht ausgeführt werden; sein Commit-Status wurde nach der bereits abgeschlossenen manuellen Veröffentlichung auf `success` korrigiert. Gitea 1.26.4 bietet keinen API-Endpunkt zum Abbrechen einzelner Runs. Verändere deshalb nicht direkt die Gitea-Datenbank.
 
-Bevor später ein Runner aktiviert wird, müssen die alten wartenden Release-Runs in Gitea bereinigt werden. Andernfalls könnten sie veraltete Images erneut als `stable` veröffentlichen.
+Bevor Actions oder ein Runner später aktiviert werden, muss Run 7 in der Gitea-Weboberfläche abgebrochen werden. Andernfalls könnte er das veraltete Image erneut als `stable` veröffentlichen. Aktiviere Actions erst danach und nur zusammen mit einem funktionsfähigen Runner.
 
 ### Manueller Multi-Arch-Fallback
 
@@ -185,6 +190,7 @@ Baue und pushe anschließend beide Plattformen in einem gemeinsamen Manifest:
 docker buildx build \
   --builder domain-control-release-builder \
   --platform linux/amd64,linux/arm64 \
+  --build-arg "VERSION=$VERSION" \
   --tag "git.j-mahler.de/admin/domain-control-webinterface-prod:$VERSION" \
   --tag "git.j-mahler.de/admin/domain-control-webinterface-prod:stable" \
   --label org.opencontainers.image.source=https://git.j-mahler.de/admin/hetzner-api-dyndns-records-webinterface \