fix(turbopack-node): make process_pool inert on wasm (#97858)
> Replaces #97584, which was **not merged**. Reordering this stack
briefly left that PR
> pointing at a base branch that had come to contain its own head
commit, so GitHub closed it
> as merged and deleted its branch. Nothing from it reached `canary`. It
had been approved;
> this PR is the same commit (`fb0b97fd84`), restored, and needs review
again. Sorry for the churn.
### What?
`turbopack-node`'s `process_pool` feature is inert on wasm, leaving
`worker_pool` as the only Node
backend there.
### Why?
The child-process pool needs `tokio::process` and a TCP listener,
neither of which exists on wasi:
```
error[E0432]: unresolved import `tokio::process` # gated #[cfg(not(target_os = "wasi"))] in tokio
error[E0599]: no `TcpListener::bind` on wasi
--> turbopack/crates/turbopack-node/src/process_pool/mod.rs:315
```
Turning the feature off from the outside is not possible: `process_pool`
is a **default** feature of
both `turbopack-node` *and* `next-core`, so `--no-default-features` at
the top level does not
suppress it.
`worker_pool` — Node worker threads over napi — is already a first-class
alternative selected by
`TurbopackPluginRuntimeStrategy`, so no new mechanism is needed.
### How?
Gate the seven `process_pool` sites on `not(target_family = "wasm")`:
the module, the sealed backend
impl, the constructor, the config enum variant, the default-strategy
selection, and the `next-api`
import and match arm. Host feature semantics are unchanged.
<!-- NEXT_JS_LLM -->
<!-- fleet b6d0486f-97c7-42a7-bdaf-3490774cdec3 -->
Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
