docs: CHANGES entry for #144 in English, heading matches its bump title

Files changed:
- CHANGES.md

CHANGES.md

@@ -359,28 +359,22 @@ byte-identical to before. `cli.py`'s and `_util.py`'s lookup of the running comm
 `cli_contract` path is now one shared function, `cli_contract.path_of`, in place of a private
 copy that used to live only in `cli.py`.
 
-### network: Eigenschaft definiert; sync, publish und upstream merge als netzwerkend markiert
+### network: property defined; sync, publish and upstream merge marked networked
 
-Gitea #144: `network:` blieb undefiniert und stand mit dem Code sowie mit sich selbst im
-Widerspruch. `sync` und `publish` (`git_publish.py`) sowie `upstream merge` (`upstream_cmd.py`)
-sprechen ein Git-Remote an (`fetch`, `ls-remote`, `push`), trugen aber `network: no`; `upstream
-verify` liest nur bereits geholte Refs und bleibt zu Recht bei `no`. Gleichzeitig behauptete
-`version check`s Datensatz, mit `version notes` eines von nur zwei netzwerkenden Kommandos in
-`wikitool` zu sein - während `review`, `task new`/`task list`/`task close` und `doctor` seit
-Gitea #121 ebenfalls `network: yes` tragen. Drei weitere Docstrings wiederholten dieselbe
-Ausschließlichkeit: der Modul- und der Befehls-Docstring von `version_cmd.py` sowie
-`fetch_latest`s Docstring in `version.py`, dessen Behauptung „the one place that talks to a
-remote host" auch unter der bisherigen, engen Lesart falsch war, da `tasks/caldav.py` und
-`tasks/superproductivity.py` ebenfalls per `urllib` sprechen.
-
-Entschieden (Operator, 2026-09-26): `network:` meint jeden Netzzugriff, gleich ob per HTTP aus
-`wikitool` selbst oder per Git-Operation gegen ein Remote - maßgeblich ist, was möglich ist,
-nicht was im Normalfall passiert, und ein Git-Aufruf, der nur lokale Refs liest, zählt nicht.
-Diese Bedeutung steht jetzt im Docstring von `cli_contract.Network`. `sync`, `publish` und
-`upstream merge` tragen `network: yes`; alle vier überzähligen bzw. falschen Textstellen sind
-korrigiert, ohne eine neue Zahl zu behaupten. Ein neuer Test schreibt die Menge der `network:
-yes`-Pfade explizit fest, damit ein künftiger Wechsel eine bewusste Teständerung ist statt
-stillen Auseinanderlaufens.
+The `network:` property had no written meaning, and the records disagreed with the code and with
+each other. `sync`, `publish` and `upstream merge` talk to a git remote (`fetch`, `ls-remote`,
+`push`) but said `network: no`, while `version check`'s record called itself one of only two
+networked commands - next to `review`, `task new`/`list`/`close` and `doctor`, all of which
+already said `yes`. `cli_contract.Network` now carries the meaning: `yes` when at least one path
+through the command can reach an endpoint outside the checkout, by an HTTP call of `wikitool`'s
+own or by a git operation against a remote; what is possible counts, not what is usual, so
+`--offline`, `--no-fetch` or a local-path remote does not turn it back to `no`, and a git call
+that only reads refs already on disk is not network access. `sync`, `publish` and `upstream
+merge` now say `yes`; `upstream verify` only reads fetched refs and stays `no`. The count claim
+is gone from `version check`'s record, from two docstrings in `version_cmd.py`, and from
+`version.fetch_latest`, which claimed to be the only place talking to a remote host although the
+CalDAV and Super Productivity providers do too. A test over the real registry pins the set of
+`network: yes` commands, so a change to it is an edit to that test rather than silent drift.
 
 ---