fix(calendar): replace add-mo panic with ILO-R009 on out-of-range

[danieljohnmorris]

Summary

add-mo was crashing the interpreter with a Rust panic in debug builds (and silently producing wrong dates in release) when called with extreme month offsets like add-mo 0 2147483647. The bug landed with #495 (calendar arithmetic). The runtime should surface ILO-R009 cleanly so agents can recover, not panic — and never silently return the wrong date in release.

Root cause

src/interpreter/mod.rs::add_months_snap did its year arithmetic in i32:

let total = date.year() * 12 + (date.month() as i32 - 1) + months;

With months = i32::MAX, 1970 * 12 + 2147483647 overflows i32. Debug panics with attempt to add with overflow; release silently wraps to a valid (but wrong) NaiveDate, so the from_ymd_opt guard never tripped and the documented "result out of calendar range" error was unreachable.

The dedicated regression test add_mo_result_out_of_calendar_range was passing in release (silent wrap landed in chrono's range by luck) and crashing in debug.

Repro

$ cargo test --features cranelift add_mo_result_out_of_calendar_range
thread 'main' panicked at src/interpreter/mod.rs:2009:21:
attempt to add with overflow

After the fix:

$ cargo test --features cranelift add_mo_result_out_of_calendar_range
test add_mo_result_out_of_calendar_range ... ok

What's in the diff

• fix(calendar): widen add-mo month arithmetic to i64 — compute total months in i64, narrow to i32 via try_from when constructing the date. Overflow now propagates cleanly to the existing None → ILO-R009 arm.
• test(calendar): pin add-mo overflow boundaries + large-but-valid offsets — adds symmetric i32::MIN negative case, a 1000-year-forward "still valid" guard so the fix doesn't over-reject, and an examples/add-mo-out-of-range.ilo exercising the same path through the examples_engines harness.

VM and Cranelift route through the tree-bridge for add-mo, so a single fix in the interpreter covers all three engines.

Test plan

• cargo test --features cranelift --test regression_calendar_arithmetic — 36/36 in debug
• cargo test --release --features cranelift --test regression_calendar_arithmetic — 36/36 in release
• cargo fmt --check clean
• Example runs end-to-end via ilo run and the examples_engines harness

Follow-ups

None directly tied to this fix. Pre-existing clippy + JIT test failures on main (the OP_TAILCALL match-arm warnings and various vm::jit_cranelift::tests cases) are not from this change and will need separate attention.

[codecov]

❌ 2 Tests Failed:

Tests completed	Failed	Passed	Skipped
1828	2	1826	0

View the top 2 failed test(s) by shortest run time

ilo::vm::compile_cranelift::tests::aot_sequential_cross_function_calls

Stack Traces | 2.96s run time

thread 'vm::compile_cranelift::tests::aot_sequential_cross_function_calls' (32699) panicked at src/vm/compile_cranelift.rs:5170:9:
assertion `left == right` failed: dbl(5)=10, triple(10)=30
  left: "nil"
 right: "30"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

ilo::vm::compile_cranelift::tests::aot_pipe_chain

Stack Traces | 3.03s run time

thread 'vm::compile_cranelift::tests::aot_pipe_chain' (32698) panicked at src/vm/compile_cranelift.rs:5188:9:
assertion `left == right` failed: 4*5+3=23
  left: "nil"
 right: "23"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}