library/unwind/src/libunwind.rs has a cfg dispatch on
(target_arch, target_os) for unwinder_private_data_size. There's an
arm for wasm32-emscripten but none for wasm64-emscripten, so
building std for wasm64-unknown-emscripten (consumed as a tier-3
target via a custom JSON spec and -Z build-std) fails with
E0425: cannot find value 'unwinder_private_data_size' in this scope.

This PR adds the missing arm, mirroring the existing
wasm32-emscripten value of 20. The constant is a count of
_Unwind_Word fields in _Unwind_Exception, not a byte size, so the
same value is correct for both pointer widths — Emscripten's libunwind
is what determines how many private words the struct needs (~18 for
the libcxxabi __cxa_exception overlay, plus the standard Itanium
private_1 / private_2), and that count is target-uniform.

 #[cfg(all(target_arch = "wasm32", target_os = "emscripten"))]
 pub const unwinder_private_data_size: usize = 20;
+
+#[cfg(all(target_arch = "wasm64", target_os = "emscripten"))]
+pub const unwinder_private_data_size: usize = 20;

 #[cfg(all(target_arch = "wasm32", any(target_os = "linux", target_os = "wasi")))]
 pub const unwinder_private_data_size: usize = 2;

Context

wasm64-unknown-emscripten isn't an officially listed target, but it's
buildable today as a tier-3 target via a custom JSON spec mirroring
wasm32-unknown-emscripten with arch=wasm64,
target-pointer-width=64, and Emscripten's -sMEMORY64=1 in
post-link-args. The motivation is running LLM inference workloads
whose working set exceeds 4 GiB (model tensors + KV cache + compute)
in a browser via Emscripten, which is impossible on wasm32 regardless
of how the bytes are loaded.

Without this arm, std itself fails to build because the unwind
crate is foundational — any crate using String / Vec / etc.
transitively pulls in unwind. With it, the entire toolchain chain
(rustc → wasm-bindgen-cli → emcc post-link with -sMEMORY64=1 -fwasm-exceptions) links cleanly and the resulting wasm runs
real-world inference workloads end-to-end. Verified with Gemma 3 4B
(~3.5 GiB on-disk; ~5 GiB working set) on Node 22.

Test plan

No new tests needed — the change is a single const for an inactive
target. Existing CI continues to skip wasm64-emscripten (not in
src/tools/build-manifest / dist-various-2).

Manual verification: cargo +nightly build --target wasm64-unknown-emscripten.json -Z build-std=panic_abort,std -Zjson-target-spec succeeds for a minimal String-using crate
with this patch; fails with E0425 without it.

Prior art for similar arms

The cfg chain in this file already has dedicated arms for several
tier-3 / late-tier-2 targets — riscv32/riscv64, hexagon,
loongarch32/loongarch64, wasm32-wasi, wasm32-emscripten. This
PR follows the same pattern, adding only the missing
wasm64-emscripten line.