docs(changelog): condense to user-facing entries; collapse internal tooling

The changelog mixed user-facing changes with dev-only maintainer tooling
(the release pipeline, CI fixes), reading as overly detailed/unprofessional.
Establish the convention up front — user-facing changes only; internal work
lives in git history — and apply it:

- Collapse the dev-only release-tooling versions 0.9.59–0.9.68 into a single
  terse 0.9.68 "Intern" entry (kept parseable so the Versions page still lists
  the running version).
- Trim 0.9.58 to its user-facing parts (GitHub update-check, public address).
- Reduce 0.9.57 to the user-facing release-channels note.

Verified the Versions-page changelog parser still yields clean nodes
(0.9.68 -> Intern, 0.9.58, 0.9.57, ...) with no leaked translation keys.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

CHANGELOG.md

@@ -9,109 +9,37 @@ reif, wird er nach `main` gemerged, als `vX.Y.Z` getaggt und hier unter einer
 eigenen Versionsüberschrift dokumentiert. Nutzer beziehen ausschließlich
 getaggte Releases (Kanal `stable`, optional `beta`) — niemals Entwicklungs-Builds.
 
+**Was hier steht:** nur, was Nutzer der Installation merken — knapp, ein Eintrag
+pro Änderung, gruppiert nach _Hinzugefügt / Geändert / Behoben / Sicherheit_. Rein
+interne Arbeit (Wartungs-Tooling, CI, Refactorings, Tests) gehört nicht hierher,
+sondern in die git-Historie.
+
 ## [Unreleased]
 
 _Keine offenen Änderungen — der nächste Stand wird hier gesammelt und als `vX.Y.Z` getaggt._
 
 ## [0.9.68] - 2026-06-23
 
-### Hinzugefügt
+### Intern
-- **Veröffentlichen + Zurückziehen auf der Release-Seite.** Bei laufender Beta: **Deploy to Public**
+- **Release-Tooling im Dev-Dashboard + CI-Pipeline.** Beta schneiden, Live-Pipeline-Status,
-  (Beta in den öffentlichen Beta-Kanal) und **Promote to Stable** (als `vX.Y.Z` in den Stable-Kanal) —
+  Veröffentlichen / Promote-to-Stable / Yank — für Nutzer der Installation nicht sichtbar.
-  beide lösen per GitHub-API (`workflow_dispatch`) die Promote-Workflows aus. Plus **Yank**: ein Public-
+  Details in der git-Historie. (Sammelt die internen Versionen 0.9.59–0.9.68.)
-  Release zurückziehen (löscht den Tag auf `clusev/clusev` über einen neuen `yank.yml`-Workflow), mit
-  Liste der letzten Public-Tags. Alle mit R5-Bestätigung + Audit; der Dashboard-Token triggert nur, der
-  eigentliche Public-Push/-Delete läuft im Workflow mit `PUBLIC_REPO_TOKEN`. (Token braucht `Actions: Write`.)
-
-## [0.9.66] - 2026-06-23
-
-### Geändert
-- **Pipeline-Leiste zeigt nur noch die Bau-Bereitschaft** (Tag → Mirror → CI). Der vierte
-  „Test-Server"-Schritt ist raus: „Staging" ist kein einzelner Server — jeder Server auf Kanal=beta
-  zieht eine Beta selbst, also war ein per-Server-„deployt"-Schritt willkürlich. Ob ein bestimmter
-  Server die Beta fährt, sieht man auf dessen Versions-Seite, nicht im Dev-Dashboard.
-
-## [0.9.64] - 2026-06-23
-
-### Behoben
-- **CI vollständig grün.** Nach dem Build-vor-Tests-Fix (0.9.63) erreichte CI erstmals den
-  `pint --test`-Schritt und meldete vorbestehende Style-Verstöße (routes/web.php + Tests). Per `pint`
-  bereinigt — Test, Style und shellcheck laufen jetzt durch.
-
-## [0.9.63] - 2026-06-23
-
-### Behoben
-- **CI war auf jedem Tag rot.** Der `php artisan test`-Schritt lief vor `npm run build`, also fehlte das
-  Vite-Manifest (`public/build/manifest.json`, gitignored → auf einem frischen CI-Checkout nicht da) —
-  jeder Voll-Seiten-Test, der ein `@vite`-Layout rendert, lief auf 500. Build jetzt vor den Tests; CI grün.
-
-## [0.9.62] - 2026-06-23
-
-### Geändert
-- **Release-Pipeline ist jetzt live.** Die Pipeline-Leiste der Dev-Release-Seite zeigt für die zuletzt
-  geschnittene Beta den **echten Status** pro Schritt statt einer statischen Legende: Tag (Gitea) ·
-  Mirror (GitHub-privat, via GitHub-API) · CI (GitHub-Actions-Run-Status) · **Test-Server** (pollt ein
-  konfigurierbares `/version.json` → „läuft 0.9.x-betaN"). Jeder Schritt mit Status-Farbe (fertig/läuft/
-  fehlgeschlagen) und Live-Poll solange CI läuft. Read-only GitHub-Token + privater Slug nur aus `.env`;
-  fehlt etwas oder hängt die API → ehrlich „unbekannt", nie Crash. Klärt das Modell: „Staging" = ein
-  beliebiger Server auf Kanal=beta (kein eigener Installer), den man als Test-Server einträgt.
-
-## [0.9.60] - 2026-06-23
-
-### Geändert
-- **Release-Seite neu gestaltet.** Die Dev-Release-Steuerung war funktional, sah aber kahl aus (Version
-  + vier nackte Buttons). Jetzt im „Tactical Terminal"-System: ein Versions-Hero (Version, Kanal,
-  Quelle), **taktile Bump-Kacheln**, die den Übergang `aktuell → Ziel` mit einem Beta-Tag-Badge zeigen
-  („Nächste Beta" hervorgehoben), gestylte Lauf-/Zuletzt-gepusht-Zustände und eine **Pipeline-Leiste**
-  (Gitea → GitHub-privat → CI → Staging). Responsiv (375/768/1280), nur Theme-Tokens, R5-Bestätigung
-  unverändert.
-
-## [0.9.59] - 2026-06-23
-
-### Hinzugefügt
-- **Release-Steuerung im Dashboard (Dev-only).** Eine neue „Release"-Seite (nur sichtbar wenn
-  `CLUSEV_RELEASE_CONTROLS=true` in der Dev-`.env`) mit einem **„Deploy to Staging"**-Button: er schneidet
-  eine Beta — bumpt die Version, committet, taggt `vX.Y.Z-betaN` und pusht nach Gitea (→ Mirror → CI →
-  Staging). Das Dashboard rechnet die Ziel-Version (Patch/Minor/Major bzw. „Nächste Beta"), die
-  **Host-Brücke** macht die Git-Arbeit — der Container bekommt nie den Git-Token (gleiche Isolation wie
-  die WireGuard-Brücke). Jede Aktion mit R5-Bestätigung + Audit-Log; Preconditions (sauberer Baum, HEAD
-  gepusht, kein Downgrade) und Rollback bei Push-Fehler.
 
 ## [0.9.58] - 2026-06-22
 
 ### Hinzugefügt
-- **Update-Check unterstützt jetzt GitHub.** Bisher kannte der Versions-Check nur die Gitea-API. Damit
+- **Update-Check unterstützt jetzt GitHub.** Public-Nutzer sehen Updates aus dem öffentlichen
-  Public-Nutzer Updates aus dem öffentlichen GitHub-Repo sehen, spricht der Check je nach Host die
+  GitHub-Repo (Tags + Changelog); Dev/Staging laufen weiter über Gitea.
-  passende API: GitHub über `api.github.com` (Tags) und `raw.githubusercontent.com` (Changelog),
-  Gitea wie gehabt. Die Host-Logik liegt an genau einer Stelle (`ReleaseChecker`).
 
 ### Geändert
-- **Öffentliche Projekt-Adresse ist jetzt `github.com/clusev/clusev`.** README, Quelltext-/Konsolen-Branding
+- **Öffentliche Projekt-Adresse ist jetzt `github.com/clusev/clusev`.** README, Quelltext- und
-  und die Standard-Update-Quelle zeigen aufs öffentliche Repo. Dev/Staging überschreiben das weiterhin
+  Konsolen-Branding sowie die Standard-Update-Quelle zeigen aufs öffentliche Repo.
-  per `CLUSEV_REPOSITORY` in der (gitignorierten) `.env` — es steht keine private URL in versionierten Dateien.
-
-### Behoben
-- **Interne Dev-Dokumente landen nicht im Public-Repo.** Die Release-Promotion kopiert nur lauffähigen
-  App-Code: `CLAUDE.md`, `rules.md`, `handoff.md` und `docs/` sind als `export-ignore` markiert und werden
-  von `git archive` (und damit `promote.sh`) ausgelassen — `CHANGELOG.md` bleibt bewusst öffentlich, weil
-  die Versions-Seite ihn vom Public-Repo abruft.
-- **Update-Check-Tests sind jetzt hermetisch.** Sie setzen die Repository-URL selbst (neutraler Host) statt
-  sich auf die `.env` zu verlassen — so laufen sie auch in CI mit leerer `.env.example` grün.
 
 ## [0.9.57] - 2026-06-22
 
 ### Hinzugefügt
-- **Release-Pipeline (Grundgerüst, Phase A).** Vorbereitung für die Verteilung über drei Repositories
+- **Release-Kanäle `stable` und `beta`.** Nutzer beziehen stabile Releases (`vX.Y.Z`); wer früher
-  (Gitea → GitHub-privat → GitHub-public). Alles **URL-agnostisch** — es wird **keine private
+  testen will, wählt den Beta-Kanal (`vX.Y.Z-betaN`) — niemals Entwicklungs-Builds.
-  Repository-URL in versionierten Dateien** abgelegt: `config/clusev.php` setzt `repository` jetzt aus
-  `CLUSEV_REPOSITORY` (Default leer), und `install.sh`/`update.sh` leiten diesen Wert aus dem
-  Klon-Ursprung in die (gitignorierte) `.env` ab — dev zeigt so auf Gitea, Public-Nutzer aufs
-  Public-Repo, automatisch.
-- **GitHub-Actions-Workflows.** `ci-staging` (Tests bei `v*`-Tags, optionaler Staging-Deploy bei Betas
-  über einen self-hosted Runner) sowie `promote-public` und `promote-stable` (`workflow_dispatch`,
-  abgesichert über das Environment „production"). Ein neues `scripts/promote.sh` überträgt je Release
-  einen **sauberen Baum** (ohne `.git`/`.github`) ins Public-Repo, sodass private CI nie öffentlich wird.
-- **Kanäle:** Beta = `vX.Y.Z-betaN`, Stable = `vX.Y.Z`. Dokumentiert in der README („Release pipeline").
 
 ## [0.9.56] - 2026-06-22