feat: changelog entries stay compact - one paragraph per topic, a size budget in docs verify and version release, version bump names required migration documents (#184)

Files changed:
- CHANGES.md
- DEVELOPMENT.md
- VERSION
- instructions/dev/stack-build/SKILL.md
- instructions/dev/version-parts.md
- instructions/migrate-corpus.md
- tools/CONTRACT.md
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/version_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_version_cmd.py
- tools/chemenu/version.py

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

DEVELOPMENT.md

@@ -90,11 +90,11 @@ eine Sitzung ihn tatsächlich durchläuft:
    `medium`) gruppiert den Eintrag; `tools/wikitool version regrade` korrigiert eine Note später,
    wenn der Gesamteindruck des Kandidaten den Blick auf einen früheren Bump ändert.
 
-2. **Der Eintrag bekommt seine Prosa - zweigeteilt.** `bump` schreibt nur das Skelett (Heading,
-   Datum, Autor, die maschinenverwaltete, gruppierte Bump-Titel-Liste, ggf.
-   Breaking-/Migration-Zeile). Darunter kommen zwei Autorenanteile: eine kurze Zusammenfassung
-   (ein paar Sätze, worum es in diesem Release geht) direkt unter der Liste, und darunter je Bump
-   ein eigener `### <Bump-Titel>`-Changeset-Absatz. Details dazu in
+2. **Der Eintrag bekommt seine Prosa - nur wo sie nötig ist.** `bump` schreibt das Skelett
+   (Heading, Datum, Autor, die maschinenverwaltete, gruppierte Bump-Titel-Liste, ggf.
+   Breaking- und Migrationszeile). Für eine kleinere Änderung genügt ihr Bump-Titel; eine größere
+   bekommt einen Absatz zu ihrem Thema, und vor dem Release kommt eine kurze Zusammenfassung
+   dazu. Form und Größenbudget, das `docs verify` und `version release` prüfen, stehen in
    [instructions/dev/version-parts.md](instructions/dev/version-parts.md) § The candidate model.
 
 3. **Verify laufen lassen, bevor irgendetwas gepublished wird:**
@@ -115,7 +115,8 @@ eine Sitzung ihn tatsächlich durchläuft:
    optional - ohne ihn bleibt der Titel des letzten Bumps stehen; mit ihm bekommt ein Kandidat,
    der mehrere Bump-Titel gesammelt hat, eine zusammenfassende Überschrift. Verweigert, wenn der
    Kandidat zwei oder mehr Bumps gesammelt hat und die Zusammenfassung aus Schritt 2 noch fehlt -
-   ein Kandidat mit genau einem Bump ist davon ausgenommen. Committet und pusht nichts
+   ein Kandidat mit genau einem Bump ist davon ausgenommen -, und ebenso, wenn der Eintrag sein
+   Größenbudget überschreitet. Committet und pusht nichts
    (Invariante 5 in [AGENTS.md](AGENTS.md)).
 
 5. **Publish bewegt `VERSION` auf `main`.**
@@ -136,7 +137,9 @@ eine Sitzung ihn tatsächlich durchläuft:
    **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
+   Bytes, und der Job verweigert ab 60000, bevor er einen Tag anlegt. Das ist nur das letzte
+   Netz: `docs verify` hält den obersten Eintrag schon während des Kandidaten bei höchstens
+   32000 Bytes (Schritt 2). 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