fix(wasm): #1049 instances 2+3 — wrapForI64 non-i64 return handling

[proggeramlug]

Summary

Closes the remaining two instances of #1049 (PR #1056 closed instance 1):

• Instance 2 — class-method dispatch inside the WASM body throwing Cannot convert 0 to a BigInt after the editor mounts.
• Instance 3 — TreeSitterEngine.parse(text, langId) FFI import throwing the same error from inside the WASM module, with all three args verifiably BigInt at the __classDispatch boundary.

Both originated from the same root cause as instance 1 fix but in the opposite direction: PR #1056 made wrapForI64 / wrapFfiForI64 coerce small-integer Number returns to BigInt. That fix was right for callees declared i64-return on the WASM side (the hone_editor_create handle path). But the rt namespace also includes:

• mem_call (declared f64-return — the central memory-bridge dispatcher)
• mem_call_i32 (declared i32-return)
• 24+ predicate imports with t_*_i32 signatures (is_truthy, js_strict_eq, class_instanceof, regexp_test, has_exception, …)

For those, returning a BigInt makes the WASM caller throw the inverse error: TypeError: Cannot convert a BigInt value to a number. The trap fires on the very first class_set_method mem_call inside _start, blowing up boot before any user code runs.

Fix

• Introduce __NON_I64_RETURN_IMPORTS — a hard-coded set of every rt import whose declared WASM return is i32, f64, or void. Built from the type tables in crates/perry-codegen-wasm/src/emit.rs.
• Add a coerceNumberToBigInt parameter to wrapForI64 (default true, set to false for entries in the set).
• New wrapRtNamespace Proxy threads each property name into the wrapper so it can consult the set per-import.
• wrapFfiForI64 is tightened to always route Number returns through __jsValueToBits (NaN-boxes the value so downstream WASM code that reinterprets i64 → f64 sees the original Number — previously BigInt(7) returned raw 7n which Perry mis-read as 5e-324).
• Drive-by: drop two leftover console.log("mem_call: object_*", …) debug statements from the March WASM-target landing that have been spamming stdout on every property access.

Test plan

• /tmp repro from the task (Cursor class + moveBy(5) + desiredColumn field) — boots cleanly, prints col=5 desiredColumn=5 matching node --experimental-strip-types.
• tests/wasm/run_wasm_tests.sh — was 0/20 (every test crashed with the BigInt error at boot), now 14/20 + the new regression test = 14/21 passing. The 7 still-failing tests are pre-existing output-format issues (Object.keys including __class__, partial Map/Set/JSON.stringify, regex capture index, FFI handle encoding) that surface only now that boot succeeds; they were hidden under the boot crash.
• New regression fixture tests/wasm/21_class_method_i64 — exercises class registration + i64 method dispatch + i32-return truthy check + cursor field re-read.
• Native parity fixture test-files/test_issue_1049_class_method_i64.ts — verified byte-for-byte against node --experimental-strip-types.
• cargo fmt --all clean.
• cargo build --release -p perry-codegen-wasm -p perry-runtime -p perry-stdlib -p perry clean.

No version bump or CHANGELOG.md entry per agent instructions; maintainer will fold those in at merge time.

Closes #1049.