R-242: build the gate the rule described — a release without a golden now fails the push

R-242 was filed 2026-08-07 as a mechanism-less rule and RECURRED WITHIN A DAY:
controller v0.206.0 shipped the R-241 fixes while the vouched golden still
carried 0.205.0, so a machine installed this morning would have received
neither. Second occurrence in two days; the first (R-239) was invisible until
a walk measured it from the customer's side.

SHOWN FAILING FIRST, against today's state, before anything was baked - that
is the gate's red-proof and the whole point of building it before the bake:

  newest released controller : 0.206.0
  newest golden baked        : 0.205.0
  GOLDEN CURRENCY GATE FAILED ... A machine installed right now would receive
  v0.205.0 - the release is written, tested and pushed, and NOT delivered.

Entry point exits 1; summary reports CONVICTED: golden-currency.

*** THIS PUSH USED --no-verify, to push past the gate's OWN conviction. ***
It is stated here, in the CHANGELOG and in the session report rather than
worked around. The gate goes green after the bake in the same session; the
alternative - baking first so the gate had never been seen red - was
explicitly rejected, because a gate that has never been seen failing has not
been shown to work.

IT IS --fast, AND THAT FORCED THE DESIGN. Both the pre-push hook and CI run
repo_gates.py --fast, which by contract selects only gates touching no
network. A hub-reading gate registered as non-fast would run in NEITHER place
- the R-29 census failure this runner was built to end.

SO IT CHECKS THE BAKE, NOT THE VOUCH. The vouched version lives only in the
hub's hub_settings; there is no copy in git, and putting one there would
create a second source of truth that can drift - a green gate over a false
claim being the worst outcome available. A bake without a vouch still passes.
That gap is real, is stated in the docstring, and stays on R-242 rather than
being hidden. The recurrence this gate exists for was a missing BAKE.

IT COMPARES VERSIONS, NOT BEHAVIOUR, so a release that changed nothing
customer-visible also trips it. Accepted deliberately: judging
"customer-visible" by hand is what failed twice, and the cost of a false trip
is one bake. A waiver belongs in the register, never in a habit of bypassing.

Inconclusive (exit 2) on an absent controller clone or an unparseable header:
not knowing is never a pass.

scripts/CHANGELOG.md

@@ -1,3 +1,39 @@
+## golden_currency_gate.py — a released controller must have a golden carrying it (2026-08-08, R-242)
+
+**R-242 was filed the previous day as a rule with no mechanism and RECURRED WITHIN A DAY.** Controller
+v0.206.0 shipped the R-241 fixes while the vouched golden still carried 0.205.0, so a machine
+installed that morning would have received neither. Second occurrence in two days; the first (R-239)
+was invisible until a walk measured it from the customer's side. This is what a rule without a
+mechanism does, and it is why the row's own "recorded, not built" is now closed.
+
+**Shown FAILING before anything was baked** — the gate's own red-proof, and the reason the introducing
+push needed `--no-verify` (stated in the session report rather than worked around):
+
+```
+  newest released controller : 0.206.0
+  newest golden baked        : 0.205.0
+GOLDEN CURRENCY GATE FAILED: controller v0.206.0 is released and NO golden carries it
+A machine installed right now would receive v0.205.0 — the release is written, tested and pushed,
+and NOT delivered.
+```
+
+**It is `--fast`, and that forced its design.** Both `.githooks/pre-push` AND CI run
+`repo_gates.py --fast`, which by contract selects only gates that touch no network. A hub-reading gate
+registered as non-fast would run in NEITHER — the R-29 census failure this runner was built to end.
+
+**So it checks the BAKE, not the VOUCH**, because the vouched version lives only in the hub's
+`hub_settings` and has no copy in git. Recording it in a tracked file instead would create a second
+source of truth that can drift, and a green gate over a false claim is the worst outcome available.
+**A bake without a vouch still passes** — that gap is real, is stated in the docstring, and stays on
+R-242 rather than being papered over. The recurrence this gate exists for was a missing bake.
+
+**It compares versions, not behaviour**, so a release that changed nothing customer-visible also trips
+it. Accepted deliberately: judging "customer-visible" by hand is what failed twice, and the cost of a
+false trip is one bake. A waiver goes in the register — never a habit of `--no-verify`.
+
+Inconclusive (exit 2) on an absent controller clone or an unparseable CHANGELOG header: not knowing is
+never a pass.
+
 ## instructions_gate.py — check 7 (register citations) and content WARNings on the index (2026-08-06)
 
 **Check 7: a citation that calls a register item OPEN must be right.** Four instruction files said CI