Claude gave me the following result with #9621:

<details>

### Empirical before/after (threejs, ~600 modules, sourcemap = File, real-FS `Bundler`, default allocator, 8 iters/run)

| Mode (transform behavior)                        | Metric        | Before (`f6653cb7b^`) | After (`f6653cb7b`) | Δ                     |
| ------------------------------------------------ | ------------- | --------------------- | ------------------- | --------------------- |
| **omitted** (changed code, no map)               | peak RSS      | ~97–104 MiB           | **~73 MiB**         | **−25–30 MiB (~28%)** |
|                                                  | time (median) | ~60–62 ms             | ~52–58 ms           | ~8–12% faster         |
| **null** (changed code, `map: null`)             | peak RSS      | ~97 MiB               | **~80 MiB**         | **−16 MiB (~17%)**    |
|                                                  | time (median) | ~62 ms                | ~57 ms              | ~8% faster            |
| **none** (no map-omitting transform) — *control* | peak RSS      | ~80 MiB               | ~78–80 MiB          | within noise          |
|                                                  | time          | ~56 ms                | ~56 ms              | within noise          |

Numbers were stable across 3 repeat runs each.

**Key signal:** in the *before* build, the map-omitting transform inflates peak RSS from the ~80 MiB baseline (the `none` control) up to ~97–104 MiB — that ~17–24 MiB *is* the intermediate sourcemaps. In the *after* build, `omitted` drops back to ~73 MiB (at/below baseline): the overhead is eliminated. The `none` control is unchanged, confirming the optimization is correctly scoped and doesn't regress ordinary builds.

</details>

close #5062