build-cache: PERRY_GC_MOVING_LOOP_POLLS became compile-time in #7161 but is missing from build_cache.rs env keys (#6394 rule regression)

[proggeramlug]

#7161 made PERRY_GC_MOVING_LOOP_POLLS a compile-time gate (codegen emits or omits js_gc_loop_safepoint calls per moving_safepoint_polls_enabled()), but the flag is not in build_cache.rs's env key list.

Today the per-object cache keys it correctly (verified during #7182's session: new objects with safepoints are emitted on a warm cache when the flag flips), so nothing is currently biting. But the build-level no-op probe is one -o collision away from handing someone the wrong binary for exactly the arm that must not go dark — =1 is now the ONLY configuration that exercises the evacuating minor end-to-end (see the corpus notes landed with #7179's gap test).

This is a regression of the #6394 rule ("the object cache keys ALL codegen env vars" — PR #6526). Fix: add the flag to the build-cache env key list, plus whatever sibling compile-time GC gates #7161/#7166 introduced that are missing (audit, don't just patch the one).

[proggeramlug]

Confirmed still open on main = d4ac65f21. Re-verified in the sweep #7262.

grep -rn PERRY_GC_MOVING_LOOP_POLLS crates/perry/src/
crates/perry/src/commands/compile/object_cache.rs:908
crates/perry/src/commands/compile/object_cache/object_cache_tests.rs:606

The per-object cache keys it (and has a test). crates/perry/src/commands/compile/build_cache.rs's env key list (lines 24–53) still does not contain it — the list runs PERRY_LINUX_SYSROOT … PERRY_DEBUG_INIT, PERRY_DEBUG_SYMBOLS, PERRY_LLVM_CLANG, PERRY_WRITE_BARRIERS, PERRY_SHADOW_STACK, PERRY_INLINE_SHADOW_SLOT, PERRY_DISABLE_BUFFER_FAST_PATH, PERRY_VERIFY_NATIVE_REGIONS, PERRY_UNBOXED_OBJECT_FIELDS, PERRY_TARGET_CPU, PERRY_NO_AUTO_OPTIMIZE, PERRY_DISABLE_WELL_KNOWN, PERRY_FORCE_WELL_KNOWN, PERRY_ALLOW_PERRY_FEATURES, PERRY_REQUIRE_FAITHFUL_BINDINGS.

So the state is exactly as this issue describes: nothing is biting today because the object cache saves it, and the build-level no-op probe remains one -o collision away from handing back the wrong binary for the one arm that must not go dark.

Note this got materially more load-bearing since filing. Per #7255, four of the six PR-gating matrix arms now run zero copying minors corpus-wide, so the %E%/loop_polls routes are close to the only configurations that relocate at all — and every A/B in this sweep depended on compile-time GC env being keyed correctly. PERRY_GC_ZEAL, PERRY_GC_PROTECT_FROMSPACE and PERRY_GC_FORCE_EVACUATE are run-time-only so they are not affected, but the issue's "audit, don't just patch the one" instruction is still the right scope.

[proggeramlug]

Verified fixed on current origin/main at ed97b9c by merged PR #7805 (merge commit 5f0aec5). The build-level cache fingerprint now includes PERRY_GC_MOVING_LOOP_POLLS, and codegen_env_vars_are_build_cache_inputs scans every PERRY_* codegen read so future omissions fail the unit suite; the per-object cache key remains present as well. Closing as fixed by #7805.