version notes: Fallback auf den Release-Feed, wenn die Instanz keinen lokalen Eintrag hat (#107)

Befund 2 aus dem getraceten 5.0.0-auf-6.0.0-Upgrade-Lauf. Eine ausgelieferte
Instanz bekommt CHANGES.md als Stub und dist upgrade ueberschreibt sie nie, der
Befehl konnte dort also nie antworten - an genau der Stelle, an der Breaking
Change und Migration gelesen werden muessen.

Fehlt der Eintrag lokal, wird der Feed aus update_url gefragt. Nur mit
Release-Stamp, damit Ursprungs-Repo und CI den Pfad nicht betreten koennen;
stdout traegt nur die Notes, Herkunft nach stderr; --offline verweigert den
Aufruf und nennt die release_url, so wie jeder Feed-Fehlerfall auch.

Dazu zwei seit ihrer Umsetzung falsche Eintraege aus tools/CONTRACT.md
"Future considerations" entfernt: MCP-Server-Wrapper und dist upgrade.

Files changed:
- CHANGES.md
- INSTALL.md
- VERSION
- instructions/upgrade-instance.md
- tools/CONTRACT.md
- tools/chemenu/commands/version_cmd.py
- tools/chemenu/tests/test_version_cmd.py
- tools/chemenu/version.py

instructions/upgrade-instance.md

@@ -16,12 +16,10 @@ history, takes updates by three-way merge (`tools/wikitool upstream merge`) and
 [private-instance.md](private-instance.md) instead. `git remote -v` answers which one this is:
 a clone carries an `upstream` remote pointing at the origin.
 
-**Two things this file deliberately does not know.** First, the copy you are reading shipped
-with the release this instance is *leaving*, not the one it is going to - so nothing specific to
-a particular jump is written here. That belongs to the release notes (step 2) and to the
-migration documents that arrive inside the tarball. Second, one step below works around a gap in
-the tooling rather than describing its intended shape; it says so, and says what makes it
-unnecessary.
+**One thing this file deliberately does not know.** The copy you are reading shipped with the
+release this instance is *leaving*, not the one it is going to - so nothing specific to a
+particular jump is written here. That belongs to the release notes (step 2) and to the migration
+documents that arrive inside the tarball.
 
 <!-- wikitool:toc -->
 ## Contents
@@ -59,12 +57,18 @@ fresh clone ([bootstrap.md](bootstrap.md)), and not for the clone-with-upstream
    **Breaking Change:** says what stops working and what this instance must do about it, and
    **Migration:** says whether the corpus has to be rewritten (`none required` when it does not).
 
-   `tools/wikitool version notes` is the command for that - **and on a distributed instance it
-   cannot answer**. It reads the local `CHANGES.md`, which an instance receives as a stub with no
-   version entries and which `dist upgrade` never overwrites, so the answer is an `ERROR` today
-   and at every future release. Read the release page instead: `.wikitool-release.json` carries
-   `release_url` for the human page and `update_url` for the JSON feed. This paragraph stops
-   being necessary the day `version notes` falls back to that feed.
+   ```bash
+   tools/wikitool version notes
+   ```
+
+   On an instance this answers out of the release feed, not out of the local `CHANGES.md` - that
+   file arrives as a stub with no version entries and `dist upgrade` never overwrites it, so the
+   command reads the notes off the release the feed publishes instead. Two things follow that are
+   worth knowing before reading the output. It can only ask for the feed's *latest* release, so
+   while `VERSION` still names the release being left, the version it answers with is **not** the
+   one this tree declares - it says so on stderr, and that is the normal shape here rather than a
+   fault. And if the feed cannot be reached, the error names the release page from
+   `.wikitool-release.json`'s `release_url`; read it there and continue.
 
 3. **Ask what is already outstanding, while `VERSION` is still the old one:**