WASI: NaN-boxed values passed through pointer-typed runtime parameters lose their tag on wasm32 #11412

Part of #11375 (standalone WASI target). Found while bringing up perry compile --target wasi (#11379).

What happens

Several #[no_mangle] runtime entry points declare a parameter as a pointer (*const ObjectHeader, *const ArrayHeader, …) but receive a whole NaN-boxed value in it, then inspect the tag bits. For example, js_object_get_field_by_name (crates/perry-runtime/src/object/field_get_set/get_field_by_name.rs) tests (bits >> 48) == 0x7FFE on its obj argument to recognise an INT32 class ref.

On LP64 a pointer is 64 bits wide, so the tag survives. On wasm32 a pointer is an i32: the ABI adapter (crates/perry-codegen/src/wasm32/abi_adapt.rs) has to trunc codegen's i64 to the runtime's real parameter type, and the tag is gone before the runtime sees it.

Repro, a WASI-only failure (native Perry prints object / true):

class Base { m() { return 1; } }
const B: any = Base;
console.log(typeof B["prototype"]);                              // WASI: undefined
console.log(Object.getPrototypeOf(new Base()) === Base.prototype); // WASI: false

In a 86-test sample of passing gap tests, this class accounts for most of the WASI failures that are not try/catch (#11378) or stdlib-link (#11377) failures. They surface as:

• Object.defineProperty called on non-object
• Reflect.get called on non-object
• Cannot assign to read only property 'x' of object
• static this.prototype reading undefined

The same pattern also exists in helpers that decode arr as u64 defensively. About 130 >> 48 tag tests on pointer-derived values exist in the runtime; not all are reachable with a boxed value.

Options

1. Retype the affected parameters as u64 (or a #[repr(transparent)] word type). LP64 is ABI-identical (same integer register), so native output does not change; the bodies convert once. This needs an inventory of which entry points really receive tagged values. scripts/runtime_abi_check.py could flag declarations whose runtime side is a pointer while the body does tag arithmetic on it.
2. Have codegen strip the tag at every such call site on wasm32, and give the runtime another way to recognise class refs (for example, a separate entry point). This touches more codegen.
3. Detector first: an opt-in wasm32 adapter mode that traps (or reports once per symbol) when an i64 → ptr truncation discards non-zero high bits. It pinpoints every affected entry point from the gap suite without guessing.

Option 3 seems the right first step, then option 1 per symbol.