Worker with large inline source map aborts process in V8 HandleDebugMagicComments

### Version v26.4.0 ### Platform ```text macOS 15.x arm64 ``` ### Subsystem worker_threads ### What steps will reproduce the bug? Create a worker entry file with a small amount of executable JavaScript and a very large inline `sourceMappingURL=data:...` comment, then load it in a worker with a constrained heap. Minimal repro: ```js const fs = require("node:fs"); const os = require("node:os"); const path = require("node:path"); const { Worker } = require("node:worker_threads"); const dir = fs.mkdtempSync(path.join(os.tmpdir(), "node-inline-sourcemap-oom-")); const workerPath = path.join(dir, "worker.cjs"); const source = [ 'const { parentPort } = require("node:worker_threads");', 'parentPort.postMessage("loaded");', 'parentPort.close();', "", "//# sourceMappingURL=data:application/json;base64,", "A".repeat(64 * 1024 * 1024), "", ].join("\n"); fs.writeFileSync(workerPath, source); const worker = new Worker(workerPath, { resourceLimits: { maxOldGenerationSizeMb: 16, }, }); worker.on("message", console.log); worker.on("error", console.error); worker.on("exit", (code) => { console.log("exit", code); fs.rmSync(dir, { recursive: true, force: true }); }); ``` Run: `node repro.js` ### How often does it reproduce? Is there a required condition? It reproduces consistently when the inline sourcemap comment is large enough relative to the worker heap limit. For comparison, these do not reproduce the same fatal abort: 1. Keeping the same large payload in an external worker.cjs.map file and using //# sourceMappingURL=worker.cjs.map. 2. Putting a similarly large payload in a normal non-sourceMappingURL comment. ### What is the expected behavior? Why is that the expected behavior? The worker should fail gracefully, for example by emitting an error event or exiting with a worker failure, without aborting the entire Node.js process. Ideally, parsing sourceMappingURL / debug magic comments should not internalize an arbitrarily large data URL into V8 old space …