Bridge f32/f64 across closure calls on the stack backend

[wtholliday]

Fixes #40.

Problem

On the stack backend, closure calls mishandled f32/f64 in both directions. jit, vm, and asm were correct.

The interpreter passes floats through the int window across a call boundary: op_call / op_call_closure copy arguments out of the int TOS window, and return values come back through t0. The direct-call path bridges both ends (FToBitsF/DToBitsD going in, BitsToFF/BitsToDD coming out). Both CallClosure sites did neither — they only pushed a placeholder for the Void case.

Returns (the reported bug in #40) — the next float-window op ran on an empty window, which the compiler's own balance check flagged as apply: f-window underflow at op 3 (FToBitsF): in=0 delta=-1:

apply(f: i32 -> f32) -> f32 { f(0) }
main { var x = 1.5; assert(apply((|i| x + 1.0)) == 2.5) }
# jit/vm/asm: assert(true)   stack: assert(false) -> trap

Arguments (found in review, second commit) — the mirror image. A non-literal float argument reached the callee as garbage; a literal happened to work, which is why it hid:

main { var g = (|a: f32| a + 1.0); var v = 2.0; assert(g(v) == 3.0) }
# jit/vm/asm: assert(true)   stack: assert(false) -> trap

Fix

Two helpers now own the CallClosure ABI, used by both call sites:

• push_closure_args — bridges f32/f64 args into the int window before the call.
• bridge_call_result — pushes the Void placeholder, or bridges an f32/f64 return back into the float/double window.

Test

tests/cases/lambdas/lambda_float_return.lyte covers f32 and f64 returns from a closure passed to a higher-order function, a call through a local variable holding a closure, and f32/f64 arguments passed non-literally. Golden tests run once per backend, so all of this is checked on jit/vm/asm/stack.

cargo test --workspace is green (358 lib + 4 golden + 21 lsp).

Out of scope

Two adjacent pre-existing bugs found during review, filed separately rather than expanded into this PR:

• Stack/VM: closures and function pointers with struct (sret) return types crash #44 — struct-returning (sret) closures and function pointers segfault on stack and panic on vm; the CallClosure sites also never grew the Reference/Slice parameter coercion the direct-call path has.
• Arrays of lambdas produce wrong results or crashes on every backend #45 — arrays of lambdas are broken on every backend. This is why the test covers only the local-variable CallClosure site: there's currently no working way to reach the indirect-expression site with a float-returning closure.

🤖 Generated with Claude Code