fix: release.yml sends its payload from a file and refuses notes over 60000 bytes; 8.0.0 entry condensed (#183)

The 8.0.0 release job failed with "curl: Argument list too long": the
payload was one argument over Linux's 128 KiB limit, and Gitea on MySQL
stores at most 65535 bytes of release note anyway. The payload now goes
through --data-binary @file, the notes step refuses over 60000 bytes
before anything is built or tagged, and workflow_dispatch lets a failed
release be retried on main. The CHANGES.md entry for 8.0.0 drops from
129 KB to 22 KB: one paragraph per larger change, the rest stays as a
bullet in the bump list. DEVELOPMENT.md step 6 names the limit and the
retry path.

Files changed:
- .gitea/workflows/release.yml
- CHANGES.md
- DEVELOPMENT.md

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

DEVELOPMENT.md

@@ -135,6 +135,13 @@ eine Sitzung ihn tatsächlich durchläuft:
    `setup-instance.md` und `preflight.md`, auf die der Installationssatz in `INSTALL.md` zeigt.
    **CI setzt den Tag, nie eine Sitzung** - das hält Invariante 5 intakt.
 
+   Die Release-Notiz ist der `CHANGES.md`-Eintrag; Gitea speichert auf MySQL höchstens 65535
+   Bytes, und der Job verweigert ab 60000, bevor er einen Tag anlegt. Scheitert der Job, nachdem
+   `VERSION` schon auf `main` steht, hilft weder ein Push (die Version steigt nicht noch einmal)
+   noch ein Re-run (er nimmt die Workflow-Datei des gescheiterten Commits): Ursache beheben,
+   publishen und `release.yml` per `workflow_dispatch` auf `main` starten. Die Prüfung auf ein
+   schon vorhandenes Release verhindert ein zweites.
+
 Die drei Verify-Befehle stehen oben in Schritt 3; was jeder von ihnen prüft, steht in
 [tools/CONTRACT.md](tools/CONTRACT.md) und wird dort von `docs verify` gegen die tatsächliche
 CLI gehalten. Hier steht es bewusst **nicht** noch einmal: eine zweite Beschreibung derselben