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

CHANGES.md

@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
 
 ---
 
-## 6.1.0-beta.3 - 2026-09-16 - dist upgrade: --take-release nimmt fuer einen lokal geaenderten Pfad die Release-Fassung
+## 6.1.0-beta.4 - 2026-09-16 - version notes antwortet auf einer ausgelieferten Instanz aus dem Release-Feed
 
 **Author:** Torben Nehmer
 
@@ -67,6 +67,7 @@ concern - readable here, never shipped as something to parse.
 - Upgrade-Prozedur als eigene Instruktion statt als Prosa in INSTALL.md
 - Migrationsdokument prueft gegen eine festgehaltene Vorher-Ausgabe, Beispielverweis auf die .template-Form
 - dist upgrade: --take-release nimmt fuer einen lokal geaenderten Pfad die Release-Fassung
+- version notes antwortet auf einer ausgelieferten Instanz aus dem Release-Feed
 <!-- /wikitool:bumps -->
 
 ### Upgrade-Prozedur als eigene Instruktion statt als Prosa in INSTALL.md
@@ -208,6 +209,49 @@ des Mass-Update-Gates, und sagt ausdruecklich, dass keine davon der Default ist.
 
 `instructions/upgrade-instance.md` Schritt 6 traegt entsprechend nicht mehr die Drei-Schritt-Handreparatur, sondern die Entscheidung und den Dry-Run, mit dem man sie vorher sieht.
 
+### version notes antwortet auf einer ausgelieferten Instanz aus dem Release-Feed
+
+`version notes` liest die lokale `CHANGES.md`. Eine ausgelieferte Instanz bekommt die aber als
+neunzeiligen Stub ohne einen einzigen Versionseintrag, und `CHANGES.md` steht in
+`chemenu.ownership.is_upgrade_preserved` - `dist upgrade` ueberschreibt sie also nie. Der Stub
+bleibt der Stub, dauerhaft. Der Befehl konnte dort nicht nur heute nicht antworten, sondern nie,
+und das an genau der Stelle, an der die Antwort am meisten zaehlt: dem Grenzuebertritt, vor dem
+**Breaking Change:** und **Migration:** gelesen werden muessen. Der getracete
+5.0.0-auf-6.0.0-Lauf kam nur weiter, weil er die Release-Notes ueber einen MCP-Server holte - ein
+Weg, den die Anleitung nicht nannte und den eine Instanz ohne erreichbaren Server gar nicht hat.
+
+Fehlt der Eintrag lokal, fragt der Befehl jetzt den Feed aus `update_url` - denselben, den
+`version check` benutzt - und druckt den `body` des Release, den `release.yml` im Ursprungs-Repo
+ohnehin aus `version notes` baut. Drei Praezisierungen halten das von einem stillen Netzaufruf
+auseinander:
+
+- **Nur mit Release-Stamp.** Ein Baum ohne `.wikitool-release.json` ist ein Dev-Checkout und
+  behaelt die alte Fehlermeldung. Damit kann der neue Pfad im Ursprungs-Repo und in CI nicht
+  betreten werden - auch nicht von `release.yml`s eigenem `version notes`.
+- **stdout traegt nur die Notes.** Die Zeile, welcher Feed gefragt wird, und die, welche Version
+  geantwortet hat, gehen nach stderr. `release.yml` leitet stdout in die Datei um, die es als
+  Release-Body postet; alles andere dort waere Inhalt im Release.
+- **`--offline`** verweigert den Aufruf und scheitert mit der `release_url` aus dem Stamp. Dieselbe
+  Seite nennt auch jeder Fehlerfall des Feeds, damit ein Lauf, der die Notes nicht lesen kann,
+  wenigstens weiss, wo sie stehen. Ein leerer `body` ist ebenfalls ein Fehler: eine leere Antwort
+  darf nicht als "dieses Release hat nichts zu melden" durchgehen.
+
+Gefragt werden kann nur das **neueste** Release: `update_url` ist die einzige URL, die der Stamp
+fuehrt, und eine `/releases/tags/<tag>`-URL daraus zusammenzusetzen waere eine geratene
+API-Form statt einer gelesenen (Invariante 7). Antwortet der Feed eine andere Version als die
+gefragte, wird das auf stderr benannt und die Notes werden trotzdem gedruckt - das ist nicht der
+Randfall, sondern der Hauptfall, weil die Notes *vor* dem Tausch gelesen werden, wenn `VERSION`
+noch das Release nennt, das verlassen wird.
+
+`instructions/upgrade-instance.md` Schritt 2 und INSTALL.md § "Version und Updates" tragen
+entsprechend nicht mehr den Hinweis, dass der Befehl auf einer Instanz nicht antwortet; damit ist
+auch die letzte der beiden Werkzeugluecken aus dieser Instruktion heraus, und ihr Vorwort nennt
+keine mehr.
+
+Bei der Gelegenheit zwei Eintraege aus `tools/CONTRACT.md` § "Future considerations (not
+implemented)" entfernt, die dort seit ihrer Umsetzung falsch standen: der MCP-Server-Wrapper und
+`dist upgrade` selbst. Beide sind im selben Dokument weiter oben als existierend beschrieben.
+
 ---
 
 ## 6.0.1 - 2026-09-16 - docs toc/verify erreichen die .template-Form einer Referenzdatei