[turbopack] defer NFT module content hashes (#97773)
### What?
Separate trace-graph module path collection from module content hashing.
Exclusion filtering now requests only cached module identifiers, while
full NFT data still layers content hashes on top when they are required.
### Why?
Applying output-file-tracing exclusion globs needs module paths but not
content hashes. Keeping these computations separate avoids requesting
full-graph hashes solely to decide which modules should be skipped.
This is an inspection experiment, not a demonstrated performance
improvement. A seven-sample release A/B left the median compilation
phase unchanged at 2700 ms.
### How?
A private identifier-only graph task owns the existing DFS traversal.
`traced_module_data_for_graph` reuses those identifiers and computes
hashes for its full result. `traced_modules_for_entries` drops the
unused hash-salt input and consumes only identifiers for glob matching.
### Verification
- `cargo fmt -- --check`
- `cargo check -p next-api`
- `next-server.js.nft.json`: byte-identical SHA-256
`da4c5a494efbbb38eb966066115de96adb5d0ec693fba17bbed669c99cafae43`
- `next-minimal-server.js.nft.json`: byte-identical SHA-256
`7c58d40dc2ecbe6ddd26dd0c602467d80f1a8ea3320e2c6e8e5f4d6be14156cd`
- Not run: clippy, Rust test suite, or integration tests (inspection
experiment)
<!-- NEXT_JS_LLM -->
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>
