docs(ci): landing a PR when main moves under you (runbook + AX entry 58)

[lilyshen0722]

What

A runbook for the failure that ate six hours on 2026-09-18: four finished, gated PRs that could not be merged, rebased six times, with the blocker never once being review.

docs/runbooks/landing-a-pr-under-strict-protection.md records:

• the two settings to measure first (strict: true, and allow_update_branch: false / allow_auto_merge: false as measured today) and why they mean a green BEHIND PR is unpressed-able by anybody;
• that there is no UI remedy while allow_update_branch is false — so "Update branch" is not advice anyone can act on;
• the window arithmetic (main merging every ~20 min against a 10–14 min check set);
• patch-id as the cheap way to carry a gate across a head rewrite;
• that the base guard rejects stacked PRs by design, with the measured 14-vs-5 check counts that make the child's green short rather than clean;
• the --onto rebase for a squash-merged parent, and the verify step afterwards.

Plus AX audit entry 58: pr-base-freshness.yml's comment reads as an endorsement of stacked PRs while pr-base-guard.yml, in the same directory, rejects them. I opened a stacked PR and called it "repo-idiomatic" on the strength of the first one.

Merge timing

Docs-only, no press needed now — the queue is being drained and this should wait its turn.

Verification

Doc + audit entry only; no code, no tests. Check counts and protection flags above were measured with gh api against Team-Commonly/commonly today, not quoted.

[lilyshen0722]

Added a fifth entry to Instruments that fail toward "fine" (a3b3763e): a guard that pins the wrong property is green while the defect is live.

Origin is #1799, and it is the first entry in that section whose instrument was mine, written this same session: v2-layout-invariants asserted the composed rule contained height: 32px and did not contain min-height. The --secondary rule's min-height: 36px stayed in force, the box measured 32×36 through a green suite, and the same assertion would have failed the correct fix as a regression. @ux-lead's browser gate caught it in one measurement (computed min-height: 36px).

The entry states the two rules that follow — never assert the absence of a property when the fix is an override, and name the floor/ceiling property (min-height, max-width) rather than its sibling — plus why a cleverer jsdom assertion is not the countermeasure: there is no layout engine there, so the property that decides the box is exactly the one you cannot observe.