Add wasm64-unknown-unknown target support

[audreyt]

Summary

Extend the wasm_js backend to support wasm64-unknown-unknown targets alongside existing wasm32 support, enabling getrandom to compile under the WebAssembly memory64 proposal.

Changes

All three changes are mechanical: widen target_arch = "wasm32" cfg guards to any(target_arch = "wasm32", target_arch = "wasm64").

• Cargo.toml — Gate wasm-bindgen, js-sys, and wasm-bindgen-test optional deps on both wasm32 and wasm64 OS-less targets
• src/backends.rs — Include wasm64 in the cfg_if! branch that selects the wasm_js backend
• src/backends/wasm_js.rs — Update the compile_error! guard so it doesn't reject wasm64 targets

Motivation

The WebAssembly memory64 proposal has reached standardization phase, and Rust nightly ships a wasm64-unknown-unknown target. However, wasm-bindgen has been the major blocker for actually using it — the CLI generates JS glue that assumes 32-bit pointers throughout (>>> 0, getUint32, 4-byte strides), and the runtime library hardcodes u32 for all pointer/length ABI types. With a corresponding upstream PR (wasm-bindgen#5004), the remaining gap is downstream crates like getrandom whose cfg guards are hardcoded to wasm32. Since the wasm_js backend uses crypto.getRandomValues() via wasm-bindgen — which is architecture-independent — no behavioral changes are needed; the only fix is widening the cfg predicates.

Testing

• Verified cargo check --target wasm64-unknown-unknown --features wasm_js succeeds

• Summary

Extend the wasm_js backend to support wasm64-unknown-unknown targets alongside existing wasm32 support, enabling getrandom to compile under the WebAssembly memory64 proposal.

Changes

All three changes are mechanical: widen target_arch = "wasm32" cfg guards to any(target_arch = "wasm32", target_arch = "wasm64").

• Cargo.toml — Gate wasm-bindgen, js-sys, and wasm-bindgen-test optional deps on both wasm32 and wasm64 OS-less targets
• src/backends.rs — Include wasm64 in the cfg_if! branch that selects the wasm_js backend
• src/backends/wasm_js.rs — Update the compile_error! guard so it doesn't reject wasm64 targets

Motivation

The WebAssembly memory64 proposal has reached standardization phase, and Rust nightly ships a wasm64-unknown-unknown target. However, wasm-bindgen has been the major blocker for actually using it — the CLI generates JS glue that assumes 32-bit pointers throughout (>>> 0, getUint32, 4-byte strides), and the runtime library hardcodes u32 for all pointer/length ABI types. With those issues now resolved upstream (wasm-bindgen#5004), the remaining gap is downstream crates like getrandom whose cfg guards are hardcoded to wasm32. Since the wasm_js backend uses crypto.getRandomValues() via wasm-bindgen — which is architecture-independent — no behavioral changes are needed; the only fix is widening the cfg predicates.

Testing

• Verified cargo +nightly check --target wasm64-unknown-unknown --features wasm_js -Zbuild-std=core,alloc succeeds (wasm64 is a tier 3 target requiring -Zbuild-std)
• Validated end-to-end with a real-world project (web-rwkv) compiled to wasm64-unknown-unknown — a 1.7B parameter LLM inference engine that requires >4 GB memory. The generated JS glue correctly handles model loading, tensor operations, and inference across the 64-bit boundary.