PAR: record the gates, and the one difference between the deployed and committed builds

clean_room_check OK, host ctest 55/55, CT111 shim cross-build OK on a fresh build directory, all
three as separate commands. The deployed instrument (par4) differs from the committed source only
by two RVA literals that the named constants resolve to identically -- said here rather than left
for a reader to find. Also flags that main moved under the branch, so the header must be
regenerated at merge, not hand-resolved.

findings/subsystems/roll-parity.md

@@ -502,4 +502,21 @@ extend it.
   `par-{br-p1,br-p2}` (canonical pair, unpinned, two fresh processes),
   `par-pin-a1` (canonical pair, pinned), `par-{t1-br-p1,t1-br-p2,t1-br-p3}` (`turn1-state`, three
   fresh processes, the third with façade attribution), plus `parse_airng.py`, the reader
-- Addresses: `ghidra/addresses.d/lane-par.json`
+- Addresses: `ghidra/addresses.d/lane-par.json` (2 entries; validated to a scratch path,
+  1,219 → 1,221, no duplicate names and no same-address-different-name)
+
+### Gates, run as separate commands on a fresh build directory (rules 13, 24)
+
+* `tools/clean_room_check.sh` — **OK**
+* host `ctest` — **55/55**
+* CT111 shim cross-build — **OK**, `build-shim` removed first, `par-gate-20260908T2330Z`
+
+The build **deployed to the guests** was `par4-6ba2c79-20260908T2322Z`, which differs from the
+committed source only in that the two façade hook targets were written as RVA literals rather than
+`sots::addr::cl_Chance` / `cl_RandRange`. Those constants resolve to the same two RVAs
+(`0x00178cf0`, `0x001798e0`), so the gate build and the measured build are the same instrument;
+the rename is recorded here rather than left for a reader to notice.
+
+`sots-engine` `main` moved to lane CB's merge while this lane ran, so the generated header on
+`wip/par` was regenerated against the pre-merge base. It must be **regenerated, never
+hand-resolved**, at merge time (rule 14).