`check-inert-sync-lane-conversions` is inside `test:gate`, so **the
merge gate itself is red on `main` right now**.
```
inert-sync-lane: total fell 11 -> 7.
Good news — but re-record the baseline in the SAME commit, or the allowance stays
high and the gate silently accepts that many NEW inert conversions
exit 1
```
## Cause: mine
#3137 converted `executor.ts`'s planner-evacuation guards (4 → 0 under
the current scan) and **did not re-record the baseline in the same
commit**. The gate fails an unrecorded drop by design — a stale-high
allowance is four free slots for new inert conversions — and that
requirement is stated both in its failure text and in its own test suite
(*"an unrecorded DROP fails, so the allowance cannot stay stale-high"*).
I knew the rule and still shipped without it; the drop only became
visible once the PR merged.
This PR is the baseline only: **11 → 7**, `executor.ts` 4 → 0,
`triage.ts` unchanged at 7.
## Ordering note for my two open gate PRs
#3169 and #3170 make the scan follow a sync lane through a **conditional
initializer** and through an **object literal**. `executor.ts` is
written in exactly that shape after #3137, so with those fixes the count
**rises 7 → 9** — a legitimate rise from better detection, not a
regression. That re-record belongs in #3170's own commit, which is where
the gate asks for it, and I will put it there rather than pre-baking it
here.
So the expected sequence is: **7 now**, **9 when #3170 lands**.
## Process notes
- I checked for an existing fix PR before writing this one.
- I also caught this only because I re-measured the exit code **without
a pipe**. `node gate.mjs | head` then `echo $?` reads `head`'s status
and reported 0 — the exact harness trap recorded in this program's
learnings doc, which I walked into while checking whether main was
healthy.
## Verification
- gate **exit 1 on `origin/main`**, **exit 0** here
- diff is the baseline file only
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
d7324c1a20