bug: source-map-support in run worker prevents Sentry from symbolicating uploaded source maps (no code context for task errors)

[scefali]

Provide environment information

• @trigger.dev/* v4.4.6, runtime: "node" (Node 21.7.3 worker image)
• @sentry/node v10.41.0
• Deploys via Trigger native build server / GitHub integration

Describe the bug

Summary: Trigger's managed run worker calls sourceMapSupport.install() at startup (packages/cli-v3/src/entryPoints/managed-run-worker.ts). This rewrites every Error.stack to original .ts positions at runtime, before the Sentry SDK parses it. Per Sentry's own Node.js docs, this is mutually exclusive with uploading source maps to Sentry:

"The Sentry Node.js SDK generally works well with the source-map-support package if you don't already have source maps uploaded to Sentry. However, if you are uploading source maps to Sentry, your code cannot use the source-map-support package, as it overwrites the captured stack trace in a way that prevents Sentry's source map processors from correctly parsing it."
— https://docs.sentry.io/platforms/javascript/guides/node/sourcemaps/troubleshooting_js/

The consequence: the source-map upload flow that Trigger's own Sentry guide recommends (https://trigger.dev/docs/guides/examples/sentry-error-tracking via sentryEsbuildPlugin) cannot actually symbolicate task errors. This is distinct from #2865 (upload fails) and #2920 (debug-ID injection OOMs): here the upload succeeds, but the events still never resolve.

Observed on a real task error captured via tasks.onFailure → Sentry.captureException:

• Stack frames arrive already mapped to original .ts paths (e.g. /src/trigger/ugc-seedance-generation.ts:461) — good for readability.
• debug_meta is null — the debug IDs injected by sentry-cli sourcemaps inject are keyed to the bundled .js filenames, which no longer appear in the rewritten stack, so the SDK emits no debug images.
• Sentry's symbolicator therefore falls back to a release+path source lookup and reports, for each in-app frame:

  { "type": "js_no_source", "symbolicator_type": "missing_source", "url": "/src/trigger/ugc-seedance-generation.ts" }
  

• Net result in the UI: file/line/function show (from source-map-support) but there is no code context — every frame renders empty. Uploaded artifact bundles (built .js + .js.map, debug-ID keyed) match nothing on the event.

Expected behavior

Following Trigger's documented Sentry setup should produce fully symbolicated task errors with code context in Sentry — i.e. the source-map upload and source-map-support should not silently cancel each other out.

To reproduce

1. Configure Sentry source-map upload per Trigger's guide (either sentryEsbuildPlugin, or an onBuildComplete extension running sentry-cli sourcemaps inject + upload).
2. Initialize @sentry/node in src/trigger/init.ts and capture errors in tasks.onFailure.
3. Deploy and trigger a task that throws.
4. Inspect the resulting Sentry event: debug_meta is null, errors[] contains js_no_source for each in-app .ts frame, and no code context is shown.

Suggested fixes / asks

Any one of these would resolve it:

1. A config option to disable (or make lazy/opt-out) the worker's source-map-support stack rewriting — so users who upload source maps can let Sentry symbolicate server-side. (Also helps bug: Sentry debug ID injection causes OOM during module loading #2920's OOM.)
2. Ship the original sources (or source maps with sourcesContent) into the deployed image at the path the rewritten frames reference, so Sentry's stock contextLines integration can attach code context locally without any upload.
3. Official docs/guidance stating that, because the worker uses source-map-support, Sentry source-map upload will not symbolicate task errors, and documenting the supported way to get code context.

Happy to provide a full event JSON / artifact-bundle listing if helpful.

Related: #2865, #2920