Turbopack: don't trace embedded WASM loader helpers (#97353)
### What?
Turbopack's output-file tracer no longer fails the build when a Node.js
App Route's server-external package graph reaches a `.wasm` file.
### Why?
Since Turbopack still mapped `.wasm` / `.wat` to
`ModuleType::WebAssembly`
while tracing, the generated loader's embedded runtime helper
(`[turbopack-wasm]/node/loadWasm.ts`) got pulled into the traced file
list. `NftJsonAsset` only accepts paths under `[project]` or `[output]`,
so it raised a fatal error and `next build` never finished.
### How?
`turbopack/crates/turbopack/src/module_options/mod.rs`: map WASM sources
to `ModuleType::Raw` when `analyze_mode == AnalyzeMode::Tracing`, the
same
way `.json` and `import … with { type: "text" | "bytes" }` are already
handled for tracing. The real `.wasm` file keeps its filesystem path in
the trace; no loader or embedded helper is created. Non-tracing bundling
behavior is unchanged.
Adds `test/production/turbopack-wasm-output-tracing/`, a production
regression test that fails on the recorded baseline with
NftJsonAsset: cannot handle filepath '[turbopack-wasm]/node/loadWasm.ts'
and passes with the fix, asserting the embedded helper is absent from
the
route's `.nft.json` while the real `.wasm` file is still traced.
Closes https://github.com/vercel/next.js/pull/97338
Closes https://github.com/vercel/next.js/issues/96897
Co-authored-by: vercel-fleet[bot] <308483924+vercel-fleet[bot]@users.noreply.github.com>
