Cranelift caller gets wrong Quat from LLVM callee on Win64

Summary

Had a mesh rendering with the wrong rotation in my Bevy game. Traced it
down to glam::Quat::from_rotation_x(-FRAC_PI_2) returning a different
value under cranelift than under LLVM, but only when a cranelift crate is
calling into an LLVM-compiled glam.

Quat is #[repr(C, align(16))] over [f32; 4]. Under pure LLVM the call
returns (-sqrt(2)/2, 0, 0, sqrt(2)/2) like you'd expect. Under the mixed
build the value just comes back wrong. No panic, no link warning.

Configs I tried

Bevy 0.17, rustc nightly:

Every failing row has a cranelift caller invoking an LLVM callee. Doesn't
matter whether it's static or DLL, gnu or msvc. A friend runs the same
cranelift-workspace + LLVM-deps + bevy dynamic_linking setup on
x86_64-unknown-linux-gnu with no issues, so this looks Win64-specific.

Couldn't test

• cranelift deps + dylib: won't link, looks like a separate dllexport gap
  in cg_clif.
• cranelift + msvc + dylib: won't link, blocked by #1610.
• Other types (Vec3, Transform, custom structs): haven't tested. Could
  be one cell of a wider mismatch or specific to 16-byte-aligned [f32; 4].

Related

• #1525 (abi-cafe failures): same family, but I haven't run abi-cafe to
  check whether this specific combo shows up there.
• #1530 (runtime failures with dynamic_linking): same config family,
  different symptom (crash vs wrong value). My matrix shows
  dynamic_linking isn't required for this one.

Can cut a smaller repo without Bevy if it'd help.

Start by reproducing the mixed Cranelift-caller/LLVM-callee matrix on Win64, then compare it with the pure-LLVM and pure-Cranelift rows. Focus on the #[repr(C, align(16))] Quat return and consult #1525 and abi-cafe for related ABI coverage. Done means the mixed configurations return the expected quaternion value with regression coverage.