docs(quick-260916-dcz): Betriebshandbuch Kapitel 9 (Changelog-Schritt, Gitea-Release, Seite Was ist neu), Anwender-, Entwicklungs- und CI-Handbuch

- Betrieb Kapitel 9: Vorschritt CHANGELOG.md vor dem Tag, automatischer Gitea-Release samt Verhalten bei fehlendem Abschnitt, Erstfreigabe v1.0.0 in der Vergangenheit, vierter Erkennungsweg "Was ist neu"
- Anwender: Satz zur Versionszeile in "Aufbau der Oberflaeche", neuer Abschnitt "Was ist neu" vor den Stolpersteinen, Inhaltsverzeichnis; Abschnitt "Dashboard" (dyv) unangetastet
- Entwicklung: Regel "Aenderungsliste" unter Konventionen und Fallstricke (Bauzeit-Einbettung, Importdisziplin, Kanalregel, Release-Skript)
- CI-Setup (ASCII): REGISTRY_TOKEN mit repository: write, vier Schritte im Job publish, Release je Tag, API-Basis im Job-Container

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018N9CD3ebPKm1b32bPpBknY

docs/ci-cd-setup.md

@@ -85,7 +85,7 @@ fuer die Pipeline konfiguriert. Benoetigt wird genau eines:
 
 | Secret | Beschreibung |
 |--------|--------------|
-| `REGISTRY_TOKEN` | Gitea-Zugangstoken (Access Token) mit Schreibrecht auf Pakete (`package: write`). Wird im Job `publish` fuer `docker login localhost:3002 --password-stdin` verwendet. |
+| `REGISTRY_TOKEN` | Gitea-Zugangstoken (Access Token) mit Schreibrecht auf Pakete (`package: write`) und zusaetzlich auf das Repository (`repository: write`, fuer Releases). Wird im Job `publish` fuer `docker login localhost:3002 --password-stdin` verwendet und im Release-Schritt ueber `env` als `GITEA_TOKEN` an `.gitea/scripts/publish-release.sh` gereicht -- nie als Argument. |
 
 Das Token erscheint nie im Log: es wird per `--password-stdin` uebergeben und
 Gitea maskiert Secret-Werte in der Job-Ausgabe. Das Veroeffentlichungs-Skript
@@ -118,10 +118,18 @@ aus drei aufeinander aufbauenden Jobs:
    veroeffentlichen
 
 Ablauf: `quality` -> `test` -> `publish` (jeder Job nur bei Erfolg des
-vorherigen). Der Job `publish` besteht aus drei Schritten: `actions/checkout@v4`
+vorherigen). Der Job `publish` besteht aus vier Schritten: `actions/checkout@v4`
 mit `fetch-depth: 0` (volle Historie samt Tags, sonst liefert `git describe`
-nichts), Login in die Registry (siehe Abschnitt 3) und der Aufruf von
-`.gitea/scripts/publish-images.sh`.
+nichts), Login in die Registry (siehe Abschnitt 3), der Aufruf von
+`.gitea/scripts/publish-images.sh` und der Aufruf von
+`.gitea/scripts/publish-release.sh` (legt bei Tags `v*` den Gitea-Release aus dem
+CHANGELOG-Abschnitt an; auf `main` endet er mit "nichts zu tun").
+
+Das Release-Skript spricht die Gitea-API ueber `GITHUB_API_URL` bzw.
+`GITHUB_SERVER_URL/api/v1` an -- im Job-Container ist das
+`https://git.vicolab.de`; `localhost:3002` ist von dort NICHT erreichbar (nur der
+Docker-Daemon des Hosts erreicht die Registry so). Lokal laesst sich das Skript
+mit `--dry-run --tag vX.Y.Z` pruefen, ohne Netzaufruf und ohne Token.
 
 ### Zwei Kanaele: Etiketten je Anlass
 
@@ -131,7 +139,7 @@ Das Skript `.gitea/scripts/publish-images.sh` entscheidet allein anhand
 | Anlass | Kanal (`APP_CHANNEL`) | Etiketten in der Registry |
 |--------|----------------------|---------------------------|
 | Push auf `main` | `beta` | `beta` und `latest` (`latest` ist nur ein Alias fuer `beta` und entfaellt spaeter) |
-| Tag `vX.Y.Z` | `live` | `live` und `vX.Y.Z` |
+| Tag `vX.Y.Z` | `live` | `live` und `vX.Y.Z` + Gitea-Release `Tessera X.Y.Z` mit dem CHANGELOG-Abschnitt |
 | Push auf `live` ohne Tag | -- | keine; der Lauf prueft nur (`quality`, `test`), das Skript endet mit "nichts zu tun" |
 
 Das Kanalmodell fuer den Betrieb (welcher Server welches Etikett zieht, Freigabe,