[turbopack] Remove per-shard modified counts from snapshots (#99955)
## Summary
Removes the per-shard modified counts from Turbopack's task storage.
Each snapshot now scans every shard of the task map instead of skipping
shards that report no modified tasks, and `track_modification` and its
undo no longer update a shared atomic counter.
The counter was there to solve two problems.
- **Skipping unmodified shards.** In a warm `next build` every snapshot
found modified tasks in all 4096 shards, so the counts never skipped
one. In a cold build every task is modified anyway.
- **Making a no-op snapshot cheap.** The persistence loop only snapshots
after enough foreground work has accumulated (1s by default), so a full
scan always follows real work. That makes it unlikely to be a no-op, and
limits how often it can run. Plus in dev `eviction` means unmodified
tasks will be removed from the map, so it will tend to be the case that
resident tasks are dirty
## Verification
Warm `next build` of vercel-site over 21 commits, 2 repeats, GC on. Base
is #99902's head, and the two arms differ only in this change. Both were
built with `build-native --release`, installed through `pack-next`, and
interleaved per commit. Snapshot phases were timed with a bench-only log
that isn't part of this PR.
| warm (40 pairs) | with counts | without | delta [95% CI] |
|---|---|---|---|
| wall | 52.26s | 52.59s | +0.33s [-1.09, +1.75] |
| user CPU | 155.0s | 154.0s | -1.0s [-5.3, +3.4] |
| snapshot capture | 177.9ms | 173.2ms | -4.7ms [-18.9, +9.5] |
| max RSS | 10.34 GB | 10.38 GB | |
Every interval includes zero. Tests that asserted on the counts were
reduced to the behaviour they still describe.
<!-- NEXT_JS_LLM -->
next.js
ef247bc8 - [turbopack] Remove per-shard modified counts from snapshots (#99955)
