Add a full f64 "double window" to the Stack VM

[wtholliday]

What & why

f64 was second-class in the stack VM: values rode the integer TOS window as bit patterns, paying a GPR↔FP crossing on every op, with zero fusion. The biquad_f64 benchmark exposed this — it ran ~2.9× slower than the f32 biquad (≈45 generic int-window ops per sample vs a handful of fused float-window superinstructions). This was a documented "deferred" decision (docs/FP_CODEGEN_PLAN.md §6.2, Option B).

This PR gives f64 its own parallel double register window (d0..d3 + a dfsp spill pointer) — the exact analogue of the existing f32 float window.

What changed

• ABI plumbing — thread dfsp + d0..d3 through the preserve_none handler signature; the two FP windows together use all 8 FP arg registers (v0..v7 / xmm0..xmm7), verified to stay register-resident on this target.
• Scalar *D op family — arithmetic, all six comparisons, conversions, memory load/store, the 24 math intrinsics, and print, with C handlers, bridge wiring, and stack-depth deltas. Every Type::Float64 codegen arm now targets the d-window, including call/return bridging (DToBitsD / BitsToDD) and window-aware DropD.
• Fused superinstructions (the payoff) — mirrored the f32 set: get_get_dmul_sum* (the whole biquad FMA chain → one op), get_set*D move chains, and get_f64const_dgt_jiz. A F32ConstF + F32ToF64D → F64ConstD const-fold exposes <lit> as f64 constants to the compare-branch fusion.
• Validation — double_stack_delta + an assert_d_window_balanced corpus sweep mirror the existing f-window correctness checks.
• Docs updated (Stack_VM.md, FP_CODEGEN_PLAN.md §6.2).

Results (benchmark/run.sh, 3-run avg, Stack VM)

	before	after
biquad f64	~0.363s	0.157s
biquad f32 (reference)	0.128s	0.128s (unchanged)

f64 went from ~2.9× slower than f32 to ~1.2× — a 2.3× speedup. The residual gap is f64's 2× state bandwidth, not dispatch/crossing overhead. No regression on the f32/int benchmarks.

Also fixes a latent correctness bug: f64 >, >=, and != previously fell through to integer bit-pattern comparisons (wrong for negatives / NaN / -0.0).

Testing

• cargo test --workspace green — golden tests across all four backends (jit/vm/asm/stack).
• New tests/cases/f64_window.lyte covers arithmetic, all comparisons, FMA fusion, f64-across-calls (arg/return bridging), deep expression chains (window spill), conversions, math, and struct store/load.
• biquad_f64 output identical on jit/vm/stack.
• Both window-balance assertions (f-window and d-window) pass over the full test corpus.

Reviewer notes

• The stack backend is not covered by the differential fuzzer (it only runs jit/vm/asm/llvm), so d-window correctness here rests on golden tests + the window-balance assertions. Adding a stack arm to the fuzzer is a worthwhile follow-up.
• src/stack_vm.rs (the Rust reference VM) is intentionally untouched: it's unreachable from any real path (the stack backend uses the C interpreter) and its own unit tests don't use window ops.

🤖 Generated with Claude Code