fix(wasm): #1037 — String.fromCharCode returned undefined on --target web

[proggeramlug]

Summary

Expr::StringFromCharCode and Expr::StringFromCodePoint in the WASM emitter were calling mem_call with the bridge name string_from_char_code (snake_case). The runtime's __memDispatch table only has string_fromCharCode (camelCase). The mismatch made mem_call fall through to __classDispatch(code, "string_from_char_code", []), which returned undefined. s += String.fromCharCode(0) then concatenated "undefined" (9 chars) per iteration — Ralph's 16-iter repro produced length 144 = 16 × 9.

(The "9× growth ratio matches handle-ID digit count" hypothesis from the issue comment was a coincidence: 'undefined'.length is 9.)

Fix

Two-character edit per arm — string_from_char_code → string_fromCharCode. Same bridge dispatches both String.fromCharCode and String.fromCodePoint (the StringFromCodePoint arm is currently a BMP-only stub aliased to fromCharCode).

Variant matrix (Ralph's table, all on --target wasm)

Variant	Pre-fix	Post-fix
result += 'x' (literal)	16 ✓	16 ✓
result += String.fromCharCode(0)	144	16 ✓
result = result + String.fromCharCode(0)	144	16 ✓
4-iter result += String.fromCharCode(0)	36	4 ✓
String.fromCodePoint(65)	undefined	"A" ✓

Bundled harness fix

tests/wasm/run_wasm_tests.sh was failing every test with document is not defined — wasm_runtime.js injects a <style> element at module load (document.head.appendChild) since the web-UI ship. Added a minimal document/window polyfill to the Node eval block in the runner. Local-only — CI doesn't execute this script.

Same-suite results (binary built from origin/main, my new test removed):
12 pass, 7 fail (05_objects_arrays, 10_higher_order, 11_map_set_json, 14_regex_date, 17_class_field_splice, 18_module_splice, 19_ffi_imports).
With fix applied: identical 7 pre-existing failures + 1 new passing test (20_string_from_char_code). No regressions.

Out of scope (worth a follow-up)

The audit found seven other bridge names with the same snake_case/camelCase mismatch, all in the _ => Handle instance method calls on objects catch-all in Expr::NativeMethodCall (emit.rs:5588..5840): string_char_at, string_index_of, string_to_lower_case, string_to_upper_case, string_starts_with, string_ends_with, string_pad_start, string_pad_end. They are unreachable for normal str.charAt(i) etc. — those hit emit_method_call (emit.rs:4081, camelCase, correct) — so the bugs are latent. Not touching them here to keep the PR focused on the user-visible bug from #1037; happy to sweep in a follow-up.

Test plan

• cd tests/wasm && ../../target/release/perry compile 20_string_from_char_code.ts --target wasm -o /tmp/t.html then run via the harness → len: 16 ✓
• PERRY_ALLOW_PERRY_FEATURES=1 ./tests/wasm/run_wasm_tests.sh → no new failures vs. origin/main baseline
• cargo build --release -p perry succeeds, cargo test --release -p perry-codegen-wasm succeeds
• Verify on the original @honeide/editor reproducer that the keyword-tokenizer no longer hangs (this PR fixes the underlying wasm runtime: post-parse hang — object_get_dynamic repeats indefinitely with identical args after keyword tokenizer enters its outer loop #1037 mechanism; the editor exercises it via buildBlockDepthString)

Closes #1037.