Fix safepoint stack slot reuse

[angelnereira]

Summary

Fixes #13461.

The safepoint spiller walks instructions backwards and can free a stack slot for a value defined by a safepoint instruction before assigning stack-map slots for values live across that same safepoint. If the freed slot is reused, the stack map can point at a slot that contains the instruction result rather than the value that must remain live across the call.

This changes the rewrite order so safepoint stack-map entries are assigned before result slots for that instruction are freed for reuse. It also adds the GC regression test from the issue to cover the null-reference trap that exposed this.

Testing

• cargo fmt --all -- --check
• cargo test -p cranelift-frontend safepoints
• cargo build -p wasmtime-cli
• target/debug/wasmtime wast -Wgc -Wfunction-references -Wwide-arithmetic -Wsimd -Wthreads -Wreference-types /tmp/safepoint-reload-aliased-ref-null.wast
• WASMTIME_TEST_GC_KEYWORDS=safepoint-reload-aliased-ref-null cargo test -p wasmtime-cli --test wast safepoint-reload-aliased-ref-null

[gfx]

Confirmed — this fixes #13461 on our end.

We originally hit the null reference trap in Wado, whose compiler emits Wasm GC code with (ref null $t) values that stay live across call safepoints.

What I did:

• Applied this PR's safepoints.rs reorder on top of v45.0.0 in our wasmtime fork: wado-lang/wasmtime@gfx/wasmtime-45 — fix commit 4e32285 (on top of v45.0.0 plus the regression .wast test).
• Built the Wado compiler against that fork via path deps: wado-lang/wado#1175.
• Ran our full e2e suite: the 7 tests that previously trapped with wasm trap: null reference now pass, and the suite is green. Before this fix the exact same wasm bytes ran fine on wasmtime 44 and trapped on 45, which is what led us to bisect to Handle alias values in SafepointSpiller::rewrite_use #13228.

Thanks for the quick turnaround.