CI A/B: gh-157468 without the once-per-frame guard commit

[johng]

Not for merging. This exists to get a CI signal on aarch64-unknown-linux-gnu/gcc (Release), the only job where test_gdb.test_jit currently fails on python#157766.

It is the PR branch with 290838c1ad5 Check _GUARD_BUILTINS_IS_CANONICAL once per frame reverted, sitting on the same merge of main as the current PR head, so the only difference from the red tree is that commit.

Evidence so far

tree	aarch64 Release
fork push of 290838c1ad5 (PR only, base 6dad8b88cc3)	success
upstream PR, Merge f8286174954 into e9ae46f02b0	success
upstream PR, Merge 290838c1ad5 into a3e389d46d9	failure
upstream PR, Merge e4f54de237b (PR + main)	failure

The fork builds the pushed commit directly; the upstream PR jobs build a merge with main. The exact commit that fails upstream passes on the fork, so the dedup commit alone does not reproduce it — the red trees all contain main commits that the green trees do not (e9ae46f02b0..a3e389d46d9, nine commits, none touching the JIT).

Locally the commit also does not change what gets traced: the sample's full executor graph (root trace, cold exit, stitched side-exit trace) is byte-identical across the PR base, f8286174954 and 290838c1ad5, on both the tier-two interpreter and a native-JIT build, and contains no _GUARD_BUILTINS_IS_CANONICAL at all. sizeof(_Py_UOpsAbstractFrame) is unchanged at 72 (the new bool lands in existing padding), and a full nm diff of the two binaries shows one symbol moved, by two bytes.

What each outcome means

• Red here — the commit is exonerated; the trigger is on the main side, and the underlying fragility is in the gdb JIT unwind info. Python/jit_unwind.c:311 registers a single CFI rule for every PC in a JIT region (CFA = x29+16), valid only in the executor's steady state.
• Green here — the commit is implicated despite identical traces, and the next question is what Linux traces that macOS does not.