Support float modulo instead of miscompiling it

[wtholliday]

Fixes #31.

f32 % f32 passed the type checker but no backend could compile it:

• Cranelift JIT: unreachable!("type Float32 not supported for modulo") — an internal compiler error.
• VM / stack / asm: emitted an integer IRem on float registers, silently producing garbage.

In Audulus the second case reads as a dead DSP script — outputs stuck at zero, controls unresponsive, no error anywhere.

Approach

Rather than reject % on floats (the issue's alternative), this makes it work, by lowering it to a Lyte-level function instead of adding a float-remainder instruction to four backends.

• stdlib.lyte — new __mod(f32, f32) / __mod(f64, f64) overloads implementing truncated remainder (x - y * trunc(x / y), built from the existing floor/ceil builtins).
• src/checker.rs — % now has its own builtin overload set (mod_overloads, i32/u32 only), so float % resolves through the existing operator-overload path to __mod. f32x4 % f32x4 becomes a clean type error instead of a JIT panic.
• src/compiler.rs — rewrite_overloaded_binops rewrites float Binop::Mod into a __mod call, so no backend ever sees a float modulo.
• src/{jit,llvm_jit,vm_codegen,stack_codegen}.rs — the three backends that silently emitted IRem for floats now unreachable! like the JIT already did, so a future regression is loud rather than silent.

Semantics

% follows C's fmod / Rust's %: the result takes the sign of the left operand, so -0.25 % 1.0 == -0.25. The stdlib's existing mod(x, y) stays floored (GLSL-style, sign of y), so both conventions are available; docs/tutorial.md documents the difference.

The alternative was making % floored to agree with mod() — happy to switch if you'd rather they match.

Testing

New golden test tests/cases/arith/float_modulo.lyte covers both signs, f32 and f64, and the wrap01 idiom from the issue. It passes on all five backends (jit, vm, asm, stack, llvm). Full cargo test --workspace is green, and cargo fmt --check reports no new diffs.

Notes

• Float % is now a call rather than an instruction. Correct everywhere, but in a DSP hot loop it depends on inlining to be free. If % shows up in benchmark-sensitive code, real FRem/DRem opcodes would be the follow-up.
• Unrelated, noticed while in here and left alone: integer % uses unsigned remainder in the Cranelift JIT (urem) while LLVM uses srem for i32, so those two backends disagree on negative operands.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JnL4SBHPzQ3rjj6VYmWrqb