controller v0.195.0: prove the offsite key comes back (R-200 plumbing half) -- MinAgent 0.125.0

--recover-offsite-check is a docker exec diagnostic in the shape of --print-reset-code: it
reads the customer's recovery code from STDIN, asks the agent to fetch this host's sealed
bundle and open it, and reports whether the recovered key matches the one on disk BY SHA256.
Two hashes and a verdict; never a password, never R, never a blob.

R comes from stdin and not a flag because a flag value is visible in ps, in shell history, in
a container's command line and in any transcript of the session that ran it.

IT COMPARES; IT DOES NOT INSTALL. The recovered password is never written to
offbox/repo_password -- installing changes a live box on a path nobody has walked, and that
link is next session's, with the drill around it. A test asserts the data dir is byte-unchanged
after a check; its red-proof (adding the install call) fails it.

Exit codes: 0 match, 2 clean MISMATCH, 1 a step failed -- "it failed" and "it worked and
disagreed" must never share a status. A box with no local password reports distinctly: that is
the rebuilt-box shape, where the next step is to install rather than compare.

Nothing customer-reachable ships here: no card, no form, no preview.

CHANGELOG.md

@@ -1,3 +1,38 @@
+## v0.195.0 — prove the offsite key comes back (2026-08-04, R-200 plumbing half) — MinAgent 0.125.0
+
+**The question, answered for the first time: is the offsite repository password actually recoverable
+from the hub's sealed bundle?** Yesterday's hub v0.93.0 made the key SURVIVE a re-ceremony. Nothing
+handed it back. The chain's last stretch had no client at link 6, a `--selftest`-only caller at
+link 7, and nothing at all at link 8.
+
+**`--recover-offsite-check`** — a `docker exec` diagnostic in the shape of `--print-reset-code`:
+it reads the customer's recovery code from **STDIN**, asks the agent to fetch this host's sealed
+bundle and open it (agent ≥ v0.125.0, `POST /escrow/recover-offsite-password`), and reports whether
+the recovered key matches the one on disk — **by sha256**. It prints two hashes and a verdict. Never
+a password, never the recovery code, never a blob.
+
+    docker exec -i felhom-controller /app/felhom-controller --recover-offsite-check < /root/r.txt
+
+**R comes from stdin and not a flag** because a flag value is visible in `ps`, in shell history, in a
+container's command line and in any transcript of the session that ran it — and R is the one secret
+in this system that cannot be rotated, re-issued or recovered.
+
+**IT COMPARES; IT DOES NOT INSTALL.** The recovered password is never written to `offbox/repo_password`.
+Comparing proves recoverability; installing changes a live box on a path nobody has walked, and
+"the existing repository opens under a recovered key" is a separate link with a drill around it.
+A test asserts the on-disk password and the whole data dir are byte-unchanged after a check, and its
+red-proof — adding the install call — fails it.
+
+**Exit codes are load-bearing:** `0` match, `2` a clean MISMATCH, `1` a step failed. "It failed" and
+"it worked and disagreed" must never share a status, because only one of them is a finding about the
+system rather than about the run. A box with no local password is reported distinctly too — that is
+the rebuilt-box shape, where the next step is to install rather than to compare, and reading it as a
+mismatch would be wrong.
+
+**Deliberately NOT in this release: anything a customer can reach.** No card, no form, no preview, no
+wizard. Building an interface on top of a chain nobody has walked is how the preceding three weeks
+went wrong; the interface comes next, on proven ground, and so does the wipe-and-restore drill.
+
 ## Changelog
 
 ### v0.194.0 — one operator e-mail per backup run, and nothing dropped without a trace (2026-08-03, R-182) — MinAgent: none