docs: version-parts.md dokumentiert den --migration-required-Ruecknahmepfad

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

instructions/dev/version-parts.md

@@ -157,6 +157,17 @@ the three-line test below is usually enough.
    migrate, with nothing telling it how, is a dead end. Like `--breaking`, both persist across
    later bumps of the same candidate without being repeated.
 
+   **A `--no-migration` answer can turn out wrong later in the same candidate**, and that is not
+   a hand-edit: a bump escalates, a second change lands under the same running number, and now
+   content does have to move after all. Write the migration document first, then retract the line
+   with `version bump --migration-required` - it removes the `**Migration:** none required` line
+   the earlier bump wrote, and refuses unless a document already targets the new base. Nothing
+   else takes that statement back: the line is machine-written (invariant 1), `docs verify` is
+   satisfied by its bare presence, and the escalation checks in this step run only on the bump
+   that *first* crosses the boundary - so a candidate that keeps a stale `none required` line is
+   never reported by anything. The 5.0.0 candidate is the case: it declared `--no-migration` for
+   a TOC-verification change, then absorbed a schema removal that migrates 152 pages.
+
 7. **Fix the candidate once it is ready to ship.** `version bump` only ever opens or escalates
    one; nothing turns it into a release except `tools/wikitool version release`, which strips the
    `-beta.N` suffix and closes the entry - see its row in `tools/CONTRACT.md`. That is also the