native_proof_regressions: 16 tests red on main, and the suite is not per-PR gated

[proggeramlug]

crates/perry-codegen/tests/native_proof_regressions.rs has 16 failing tests on main, verified against an unmodified tree at origin/main during #7242:

• 15 × invalidation::*
• typed_f64_receiver_method_clone_raw_loads_after_composed_guards

They are unrelated to #7242 (that PR's diff does not touch them; the same 16 fail with and without it).

Why this matters more than 16 red tests

This is the CLAUDE.md failure mode "integration suites under crates/*/tests/*.rs do not run per-PR (nightly/tag only) — a regression there can land green and sit red for days" (#5960), observed live.

These tests guard native-proof invalidation — precisely the machinery that decides when a type proof stops being valid. That is a soundness-relevant surface: #7242 was merged because an unsound specialization pass produced silently wrong arithmetic, and the suite that would notice a proof-invalidation regression is not consulted on any PR.

Asks

1. Triage the 16 — are they stale expectations, or real invalidation regressions? The distinction matters: the second case means proofs are surviving events that should kill them.
2. Get this suite (or a cargo-test-visible subset of it) into the per-PR gate, per CI: PR cargo-test never executes crates/perry integration suites; main-push full run starves under merge trains (documented near-miss) #5960's standing recommendation.
3. Whichever way (1) resolves, the suite must not be left red — a permanently-red suite trains everyone to ignore it, which is failure mode (1) by a different route.

Found during #7242. Not a blocker for it.

[proggeramlug]

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

cargo test --profile perry-dev -p perry-codegen --test native_proof_regressions
→ test result: FAILED. 235 passed; 16 failed; 0 ignored

The failing set is byte-identical to the one in this issue — 15 × invalidation::* plus typed_f64_receiver_method_clone_raw_loads_after_composed_guards:

invalidation::body_counter_mutation_does_not_emit_inbounds_buffer_gep
invalidation::body_mutation_of_local_bound_does_not_use_local_length_bound_fact
invalidation::decrementing_loop_update_does_not_emit_inbounds_buffer_gep
invalidation::inclusive_length_loop_does_not_emit_inbounds_buffer_gep
invalidation::inclusive_local_length_bound_does_not_use_local_length_bound_fact
invalidation::inner_loop_bounded_buffer_fact_is_removed_after_outer_fact_invalidation
invalidation::localset_invalidates_active_bounded_buffer_index_facts
invalidation::localset_invalidates_buffer_view_local_length_sources
invalidation::localset_invalidates_min_length_facts
invalidation::localset_invalidates_native_i32_alias_facts
invalidation::negative_loop_counter_does_not_emit_inbounds_buffer_gep
invalidation::negative_loop_counter_does_not_use_local_length_bound_fact
invalidation::negative_loop_counter_does_not_use_min_length_bound_fact
invalidation::update_invalidates_buffer_view_local_length_sources
invalidation::update_invalidates_native_i32_alias_facts
typed_f64_receiver_method_clone_raw_loads_after_composed_guards

So the count has neither grown nor shrunk across #7243/#7249/#7250/#7252/#7253/#7256 — consistent with this issue's finding that they are unrelated to #7242, and evidence that nothing is actively churning them.

Ask (1) — are these stale expectations or real invalidation regressions — is still unanswered and is the one that matters, for the reason stated: if they are real, type proofs are surviving events that should kill them, which is a soundness surface.