agent 0.130.0 published and vouched; R-347 closed, R-349 + R-350 filed

Released via scripts/release-agent.sh: tag v0.130.0 at 7569f34, sha256
a56a92a7bd68f5b46736eaec4806c3d26c16ccb35118c4ac0e3d8094eaefabc3,
verified by independent download and reproducible byte for byte with
-trimpath -buildvcs=false.

Vouched agent 0.129.0 -> 0.130.0 in the Day-0 manifest. Only the agent
fields changed: min_agent stays 0.129.0 because it states what the GOLDEN
CONTROLLER requires, and raising it would have HELD the floor for every
box below 0.130.0. Global floor untouched at 0.216.0 -- and on hub
v0.106.0 it is a separate form with its own action, so publish-train
rule 2's hazard no longer exists in the shape its incident describes.

No --no-verify: the CHANGELOG heading was flipped only after the tag and
package existed, so release-complete passes on the real artifact.

R-349: the fleet was running a DIFFERENT binary under the same version
name -- the proof deploy was a hand build, the release is -trimpath.
Self-update could never have corrected it, because every version check
compares the string. Both boxes reinstalled from the downloaded package.
The proper fix exists in miniature as wrapper_sha256 and was never
extended to the agent's own binary.

R-350: I printed the hub password into the session transcript via
curl -w '%{redirect_url}' -- the hub answers 303 and curl re-attaches the
credential. Not in git, not in any committed file, not in the evidence
directory. Rotation is the operator's call.

ep0 closes at fd 17, ESTAB 0, CLOSE-WAIT 0 -- its t0 baseline -- and was
read-only for this entire arc.

STATUS.md

@@ -132,11 +132,17 @@ record with no machine** — created 13 August, no host, no backups, nothing to
   off-site box is back to 17 open connections, its normal resting number, down from 415.** All of the
   built-up connections released themselves when the agents restarted; the off-site box was only ever
   read from, never touched. *(register: R-344)*
-- **The fix is on the two demo machines by hand and NOT published yet** (R-347). A machine installed
-  from today's image still gets the old, leaking agent. That was deliberate — publishing it mid-test
-  would have contaminated the comparison — and the reason has now expired. **It is not urgent:** a new
-  machine would take the better part of a year to matter, and any agent update clears the build-up.
-  **Publishing is your call**, and it needs the operator-only artifact screen at the end.
+- **PUBLISHED the same day, on your word** (R-347, closed). Agent **0.130.0** is released, and the hub
+  now hands it to any new machine. Both demo machines run the exact published copy. Nothing else on
+  that screen was changed — in particular the controller floor was left alone, and the "minimum agent"
+  setting too, because raising that would have **stopped** machines getting updates rather than
+  helping them.
+- **Two things the release itself turned up.** (1) The machines were briefly running a *different*
+  build of the same version number — harmless here, but nothing in the system would ever have noticed,
+  because everything compares the version *name*. Now corrected, and filed so it cannot repeat
+  (R-349). (2) **I printed the hub password into my own session log** while confirming the change
+  (R-350). It is not in git and not in any saved file — but it is in the log on this machine.
+  **Changing it is your call**; I can do it without ever showing the new one. Ask and I will.
 - **The off-site box was updated, and it did not help — as expected** (R-341). On your ruling we
   installed the newer backup software for the practice, having first read its release notes and found
   **nothing** about the fault we have. The update went cleanly and everything works, but the leak