[native/gba] #655 guard trip is uncatchable at typed call sites: 'expected number' panic fires before the pending RangeError is checked

[spacedevin]

Summary

When the #655/#680 stack guard trips inside a boxed user-fn call, enter_call_guarded parks the catchable RangeError and the call returns None → value_call yields Value::Null. But at a typed call site the generated code type-matches the result BEFORE consulting the pending throw:

bootChoice = (match &({
    let _callee = (fileselRun).clone();
    tishlang_runtime::value_call(&_callee, &[])
}) { Value::Number(n) => tishlang_runtime::to_int32(*n), _ => panic!("expected number") }) as i32;
if tishlang_runtime::has_pending_throw() { return Err(...); }   // ← never reached

So the designed catchable RangeError surfaces as an uncatchable panicked at ... expected number — on GBA that is the agb crash screen with a message that names neither the guard nor the stack. A try { } catch around the call cannot catch it. We lost most of a day to this on two ROMs: the symptom reads as a type bug in unrelated game code.

Repro

Any GBA ROM whose resting SP sits within GBA_STACK_MARGIN of __iwram_end (grow module-level code until it does, or shrink the margin locally), with a typed-annotated variable assigned from a boxed user-fn call. The call trips the guard → expected number panic instead of a catchable RangeError.

Ask

Check has_pending_throw() (or match the guard's sentinel) BEFORE the expected number type assertion at typed call sites, so a tripped guard propagates as the catchable error #655 promises. The same ordering problem presumably affects every typed lowering of a boxed call result (string/bool asserts too).