[Rspack] meteor build OOMs while linking a large non-Blaze client bundle

meteor build runs the build tool out of memory while linking the imported Rspack client output, on a non-Blaze app with a large client bundle. This was raised in #14561 / #14562 as a separate scalability concern from the Blaze loading fix, so splitting it out with a standalone reproduction.

Versions: Meteor 3.5, rspack 1.1.0, @meteorjs/rspack 2.1.0. Seen on macOS arm64 and Linux x64.

Expected: meteor build completes for a large non-Blaze Rspack client bundle.

Actual: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory (exit 134), right after => Compiled Rspack client app. So the OOM is in Meteor's link/output handling of the imported client-rspack.js, not in Rspack.

Reproduction: https://github.com/miamagana/meteor-rspack-oom-repro

meteor npm install
node generate.js
TOOL_NODE_FLAGS='--max-old-space-size=2048' meteor build --directory /tmp/out

The 2GB bound just makes it deterministic and machine-independent. A small generate.js size builds fine, which confirms the app itself is healthy.

Profile: the built client output is ~17MB of JS with a ~102MB source map. meteor build --debug (minification off) OOMs the same way, so it is not the minifier. That points at the linker/output stage, and the ~102MB source map is the prime suspect. Dev and meteor test --full-app do not reproduce it, because the Rspack dev server serves the client there so the large output is never imported and linked. It is specific to meteor build and meteor run --production.

Related: #14561 and its Blaze loading fix #14653, the serve-and-inject PR #14562, and #14464 (server-side rebuilds).