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

docs/version-model.md

@@ -83,22 +83,27 @@ matter just as much in practice: how many numbers get handed out along the way t
 release. For a while the answer was "one per bump," and that turned out to be the wrong grain
 entirely.
 
-The two things that actually consume a version number are a release and CI's version gate - and
-they disagree about granularity. The gate wants `VERSION` to move on every push that touches
-stack-shaped paths, which is a *commit*-level question: has this tree changed since the last
-push. A release wants to know something else: has *this specific number* been published, ever.
-Handing out a fresh number per bump answers the gate's question by accident and the release's
-question wrongly - it treats every bump as if it were about to ship, when most of them are steps
-toward a release that hasn't happened yet. Four bumps in one session, on the same day, for the
-same eventual release, produced four numbers that a version-check feed would have reported as
-four different available upgrades, three of which were never real.
+Two mechanisms decide when a number gets minted, and they answer different questions. CI's
+version gate asks a *commit*-level one: has this tree changed since the last push, and if so
+has `VERSION` moved with it. A release asks something else entirely: is this a state worth
+handing to someone, under a number they will pin against. Tying the second to the first - every
+`VERSION` move firing the release workflow - answers the gate correctly and the release question
+by accident, because it treats every bump as if it were about to ship when most bumps are steps
+toward a release that has not happened yet.
+
+The failure mode is not phantom numbers; every one of those releases was real, tagged and
+downloadable. It is that "real" stopped meaning anything. On 2026-09-03 this repository cut four
+releases in six hours - `4.3.0` through `4.3.3` - for one continuous arc of work, two of them for
+prose changes alone. Someone tracking the feed saw four upgrades and had no way to tell which, if
+any, was a moment worth stopping for. A release is a promise addressed to a consumer, and a
+promise made four times an afternoon is not a smaller promise, it is a less legible one.
 
 The fix is not to slow the gate down - it still wants `VERSION` to move every time, and it still
-gets that. It's to stop treating every movement as a new number. Between two releases the stack
-now carries one running candidate, escalating through `-beta.N` as bumps accumulate, and only
-`version release` spends the number for real by fixing it and closing its changelog entry. A
-number is proposed by a bump and consumed by a release; conflating the two was the actual defect,
-not the arithmetic of any single bump.
+gets that. It is to stop treating every movement as a number worth publishing. Between two
+releases the stack now carries one running candidate, escalating through `-beta.N` as bumps
+accumulate, and only `version release` spends the number for real by fixing it and closing its
+changelog entry. A number is proposed by a bump and spent by a release; conflating the two was
+the actual defect, not the arithmetic of any single bump.
 
 This is also why a candidate never gets to a distributed instance. The promise a released version
 makes - "install this, and it is exactly what its number says" - has no equivalent for something