feat: Versionskandidat statt Bump-pro-Release - VERSION traegt -beta.N, version release fixiert (4.4.0, #42)

Files changed:
- .gitea/workflows/release.yml
- AGENTS.md
- CHANGES.md
- DEVELOPMENT.md
- README.md
- VERSION
- docs/version-model.md
- instructions/dev/version-parts.md
- tools/CONTRACT.md
- tools/chemenu/commands/dist_cmd.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/doctor.py
- tools/chemenu/commands/migrate_cmd.py
- tools/chemenu/commands/version_cmd.py
- tools/chemenu/kb_state.py
- tools/chemenu/tests/test_dist_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_doctor.py
- tools/chemenu/tests/test_migrate_cmd.py
- tools/chemenu/tests/test_version_cmd.py
- tools/chemenu/version.py

CHANGES.md

@@ -18,6 +18,62 @@ heading, and `wikitool docs verify` refuses a tree whose `VERSION` and newest
 versioned entry disagree. Entries below `0.1.0` predate versioning and keep
 their date-only headings.
 
+Since `4.4.0` the stack carries **one running candidate** between two
+releases rather than a fresh version per bump - see
+`instructions/dev/version-parts.md`. While a candidate is open its heading
+names it with a `-beta.N` suffix (`## 4.4.0-beta.2 - <date> - <title>`), and
+every bump of that same candidate updates this one entry in place rather than
+opening another: the heading's version/date/title move, and the bump's
+`--title` joins a machine-managed `<!-- wikitool:bumps -->` list right under
+the entry's `**Author:**` line - written and read by `wikitool version bump`,
+never by hand. `wikitool version release` is what closes a candidate: it
+strips the suffix and turns the entry into an ordinary, suffix-free one,
+leaving the bump-title list as the record of what happened. A distributed
+instance never sees a `-beta.` version at all (`release.yml` only ever
+releases a fixed one), so this suffix and the list beneath it are a
+dev-checkout concern - readable here, never shipped as something to parse.
+
+---
+
+## 4.4.0 - 2026-09-03 - Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert
+
+**Author:** Torben Nehmer
+
+<!-- wikitool:bumps -->
+- Versionskandidat statt Bump-pro-Release: VERSION traegt -beta.N, version release fixiert
+<!-- /wikitool:bumps -->
+
+Bisher bekam jeder `version bump` sofort eine fixierte, dauerhafte Nummer, unabhängig davon, ob
+je ein Release dazu erschien - fünf Minor-Bumps ohne Release ergaben fünf Nummern, von denen vier
+nie ausgeliefert wurden. `VERSION` trägt jetzt zwischen zwei Releases **einen** laufenden
+Kandidaten (`X.Y.Z-beta.N`) statt einer neuen Nummer pro Bump: `--major/--minor/--patch`
+eskaliert diesen Kandidaten max-wins gegen den letzten Release, statt daneben eine neue Nummer zu
+schreiben, und schrittet dabei nie zurück.
+
+`Version` versteht den Suffix, mit einer expliziten Ordnung
+(`4.4.0-beta.1 < 4.4.0-beta.2 < 4.4.0`, numerisch nach `N`, nicht lexikografisch). `CHANGES.md`
+trägt genau einen offenen Eintrag pro Kandidat: der erste Bump eröffnet ihn, jeder weitere
+aktualisiert Heading und die maschinenverwaltete Bump-Titel-Liste in
+`<!-- wikitool:bumps -->` (Marker-Konvention aus `blocks.py`, aber bewusst nicht in
+`blocks.BLOCKS` - diese Region gehört zu `CHANGES.md`, nicht zu einer Seite). `version release`
+ist neu und fixiert einen Kandidaten: Suffix weg, Eintrag geschlossen, committet und pusht nichts.
+
+Vier Stellen am Bestand angepasst, die das Kandidatenmodell sonst still beschädigt hätten:
+`release.yml` überspringt einen suffixbehafteten `VERSION`-Push sauber, bevor die Releases-API
+gefragt wird, statt jeden Beta-Bump zu veröffentlichen; die Grenzübertritts-Checks in
+`docs verify` (`check_migration_for_boundary`, `check_breaking_change_for_boundary`) messen jetzt
+gegen den **letzten Release** (`version_mod.last_release`) statt gegen den zweitobersten Eintrag,
+der zwischen zwei Betas keine Grenze mehr hergibt; `kb_state.chain()`/`next_link()` vergleichen
+gegen die **Kandidatenbasis**, weil eine Migration mit Ziel `4.4.0` sonst bei installiertem
+`4.4.0-beta.1` aus dem Intervall fällt (`4.4.0-beta.1 < 4.4.0`); `read_kb_version()` verweigert
+einen Prerelease, weil eine Inhaltsform kein Beta kennt. `dist export` schreibt `VERSION` und den
+Stamp weiterhin ehrlich mit Suffix, aber `.wikitool-kb.json` bekommt die Basis.
+
+Menschendoku für die Erzeuger-Seite: `DEVELOPMENT.md` im Repo-Root, bewusst nicht in
+`dist_cmd.ROOT_FILES` (Begründung als Kommentar dort), mit Zeile in `AGENTS.md` § File naming und
+Zeiger aus `README.md`. `docs/version-model.md` hat einen neuen Abschnitt, warum eine Nummer erst
+durch ein Release verbraucht wird.
+
 ---
 
 ## 4.3.3 - 2026-09-03 - Modellwahl nach Pruefbarkeit statt nach Aufgabenname; stack-dev bricht an den Phasenwechseln fuer den Model-Switch