fix(turbopack): use file persistence on wasm - #98613

Stacked on #98495.

What?

Enable Turbo Tasks persistence on wasm32 by making file I/O the only available persistence access mode on that target. The persistence tests that previously stopped at the unsupported mmap implementation now run against the file-backed path.

Why?

WASI does not provide the memory-mapping support that memmap2 requires. Keeping AccessMode::Mmap available on wasm would leave a configuration that compiles but fails at runtime, and would require every JavaScript loader or test host to know about an internal environment-variable override.

How?

AccessMode::Mmap and its mmap-only implementation paths are compile-time excluded on wasm, so selecting mmap there is impossible rather than a runtime error. AccessMode::File becomes the only and default wasm mode. Native targets retain both modes, including the existing environment-variable behavior and mmap default.

Test-only code uses the file-backed equivalent where an mmap mode cannot exist, allowing the three kv_backing_storage persistence tests to run on WASI without weakening their surrounding behavioral assertions.

This does not claim end-to-end wasm persistence yet: the wasm binding still needs runtime initialization and package integration before a real Turbopack build can consume this path.

Testing

• cargo check -p turbo-persistence --target wasm32-wasip1-threads
• cargo clippy -p turbo-persistence -p turbo-tasks-backend --lib --tests --target wasm32-wasip1-threads -- -D warnings
• cargo test -p turbo-tasks-backend --lib --target wasm32-wasip1-threads -- kv_backing_storage::tests
• Native turbo-persistence and turbo-tasks-backend focused tests
• cargo fmt --check