docs: agent 0.120.0 published + vouched, proven on two reinstalled boxes (R-178)

v0.120.0 had been built, committed and deployed to both demo hosts but never
published: the Gitea generic package 404'd and the hub manifest vouched 0.119.0.
Installer step 5 skips only on an exact version match, so a documented-path
reinstall would have downgraded both boxes to the pre-merge agent -- and would
have succeeded, since step_grows passes -sysdata-grow 0 and 0.119.0's mp1 resize
never fires. Published from a clean tree (upload 201, round-trip GET verified,
sha a7763d31b55b5ce7...) and vouched; both reinstalls then fetched and verified
it over the real customer path.

Filed as the third instance of R-115. No version bump, nothing built.
Evidence: felhom.eu/REPORT.md

CHANGELOG.md

@@ -1,3 +1,31 @@
+## docs — v0.120.0 PUBLISHED + vouched, and proven on two reinstalled boxes (2026-08-03, R-178) — **no version bump, nothing built**
+
+**Nothing shipped in this entry.** It records an operational fact the version history could not
+otherwise carry: **v0.120.0 had been built, committed at `cd6e267` and deployed to both demo hosts,
+but never published.** `GET https://gitea.dooplex.hu/api/packages/admin/generic/felhom-agent/0.120.0/felhom-agent`
+returned **HTTP 404** (0.119.0 → 200), and the hub's Day-0 manifest accordingly vouched **0.119.0**.
+
+**Why that mattered more than it looks.** `felhom-host-install.sh` step 5 skips the binary install
+only when `installed == vouched` *exactly*, so a documented-path reinstall would have replaced the
+merge-aware 0.120.0 with the pre-merge 0.119.0 — **and would have succeeded**, because the current
+`step_grows` passes `-sysdata-grow 0` and 0.119.0's `mp1` resize (`bringup.go` 4c, fatal on error)
+therefore never fires. Both demo boxes would have come back on an agent that predates the merge while
+every log line read green.
+
+Published this session on an operator ruling, from a clean tree (`git status --porcelain` empty,
+`HEAD == origin/main == 4bb84fc3`): `scripts/publish-agent.sh 0.120.0` → upload **HTTP 201**,
+round-trip GET verified, `AGENT_SHA256=a7763d31b55b5ce75457b4dba7b06aa300325811834b0be78af4587b47110b9d`;
+then vouched in the hub manifest, which resolved the sha authoritatively from Gitea rather than
+trusting the submitted value.
+
+Both reinstalls then fetched and sha-verified it over the real customer path —
+`verified sha256 a7763d31b55b5ce7… matches the hub manifest` — and 4b's single-volume grow was
+exercised live on both boxes (`data +46G (->70G, ONE volume)` on demo-hp,
+`+226G (->250G)` on demo-felhom), each producing `mp0` at `/var/lib/felhom` with **no `mp1`**.
+
+**Filed as the third instance of R-115** (*"publishing is a remembered step"*), which has been
+WAITING-ON-OPERATOR since 2026-07-29. Full evidence: `felhom.eu/REPORT.md`.
+
 ## v0.120.0 — one data volume (2026-08-03, R-165 · decision D-a · variant V-c) — `build-golden.sh` 2.1.0 → **3.0.0**
 
 **The dedicated backup partition stops existing.** A golden built by `build-golden.sh` v3.0.0 ships a