docs: Faktenkorrekturen in der 4.4.0-Prosa; DEVELOPMENT.md ohne zweite Kommandobeschreibung (4.4.1-beta.1, #47)

Files changed:
- CHANGES.md
- DEVELOPMENT.md
- VERSION
- docs/version-model.md
- instructions/dev/version-parts.md

instructions/dev/version-parts.md

@@ -9,7 +9,7 @@ Two questions decide a version bump, and they are **not the same question**:
 
 1. **Is the new version a drop-in replacement for the old one?** This is what the version
    number itself says. Compatibility is read off the **leftmost non-zero component** - on this
-   stack (`2.x`) that is MAJOR, on a `0.x` stack it is MINOR. A bump that changes it is called
+   stack (`4.x`) that is MAJOR, on a `0.x` stack it is MINOR. A bump that changes it is called
    *boundary-crossing* below, because that is the term `version bump` and `docs verify` use in
    their own messages.
 2. **Must existing content be migrated?** This is a *consequence* a boundary crossing may or
@@ -23,11 +23,13 @@ already (see the case study at the end), which is why this file exists.
 ## The candidate model
 
 Between two releases the stack carries **one running candidate**, not a fresh version per
-`bump`. Five bumps with no release in between used to mean five numbers, four of which nothing
-ever consumed - the release-granularity CI's version gate wants (`VERSION` must move on every
-stack-touching push) was being paid at bump granularity instead. A candidate closes that gap
-without touching the gate: `VERSION` still moves on every bump, it just escalates the *same*
-number instead of handing out a new one.
+`bump`. Before that, every bump minted a number *and* a release: CI's version gate requires
+`VERSION` to move on every stack-touching push, and `release.yml` fires on every `VERSION`
+move, so releases were being cut at commit granularity. 2026-09-03 produced four of them in
+six hours (`4.3.0` through `4.3.3`) for one arc of work - all four real, none of them a
+meaningful unit to anyone downstream. A candidate closes that gap without touching the gate:
+`VERSION` still moves on every bump, it just escalates the *same* number instead of handing out
+a new one, and only `version release` turns it into something the release workflow acts on.
 
 - **State lives in `VERSION` itself**, as an optional `-beta.N` suffix (`4.4.0-beta.3`). No
   second state file: the last release is read back out of `CHANGES.md` (the newest entry with no
@@ -35,8 +37,8 @@ number instead of handing out a new one.
   release - derived, not stored.
 - **`--major`/`--minor`/`--patch` is max-wins escalation**, not a step you can undo. A `--patch`
   bump on a candidate already at MINOR only advances its bump count (`N`); nothing ever steps a
-  candidate back down. Declaring the part is still your judgment call, made the same way section
-  below describes - `escalate()` only ever raises it further.
+  candidate back down. Declaring the part is still your judgment call, made the same way the
+  steps below describe - `escalate()` only ever raises it further.
 - **A candidate is never released.** Pre-release is a dev-checkout state; `release.yml` only acts
   on a suffix-free `VERSION`, so a distributed instance never sees a `-beta.` version at all, and
   its parser never has to know the suffix exists.