gc: debug_assert!(false) inside extern "C" js_shadow_frame_pop SIGABRTs the entire dev-profile runtime test suite (invisible to release-only CI)

[proggeramlug]

cargo test -p perry-runtime --lib in the dev profile cannot complete on main: it SIGABRTs at gc::tests::shadow_stack_ops::out_of_range_frame_pop_is_ignored.

Mechanism

js_shadow_frame_pop's corrupted-handle guard uses debug_assert!(false, …) inside an extern "C" fn. In a debug build the assert fires, the panic cannot unwind across the extern "C" boundary, and the process aborts — taking the whole test binary with it.

Why nobody sees it

• CI runs the suite --release, where debug_assert! compiles out — so the gate is structurally blind to it.
• Landed with the perf(gc): make the shadow-stack runtime ops cheap #7079/perf(gc): emit the shadow-slot root store inline #7088 shadow-stack work.
• Reproduces standalone (cargo test -p perry-runtime --lib out_of_range_frame_pop_is_ignored), independent of any concurrent change — verified against pristine origin/main while validating PR fix(gc): keep live array elements traced and initialize unused array capacity #7138 (whose tests are unaffected; they run --release).

An earlier session also hit this as a pre-existing red while validating #7116 ("debug-only debug_assert!(false) — CI runs release").

Fix directions (pick one)

1. Replace debug_assert!(false, …) with a non-panicking diagnostic on the extern "C" path (#[cold] fn + once-per-process stderr, the report_growth_stub_skipped_below_heap_min pattern), keeping the guard's skip behaviour.
2. If the assert is genuinely wanted in debug runs, route it through a Rust-ABI inner fn so the panic can unwind to the test harness instead of aborting the process.

Either way, the dev-profile suite should complete on main; a whole profile of the runtime test suite being un-runnable is itself a gate that cannot fail.