Guard server runtime entries against pulling in build-time tooling #25676

Since server-side tracing in v11 relies on build-time instrumentation, build tooling keeps leaking into server runtime bundles: bundler plugins, oxc-parser, orchestrion's bundler transforms, Vite/webpack/Babel and WASM. Each time this surfaces as a different user-facing breakage, depending on what consumes the server entry. Some examples:

• @sentry/nextjs server entry re-exports withSentryConfig, pulling the orchestrion webpack plugin's WASM into the runtime bundle (CompileError on Cloudflare Workers) #22794: the Next.js server entry reached withSentryConfig, which pulled orchestrion WASM into a workerd bundle (CompileError)
• meriyah.mjs missing at runtime in Next.js "standalone" builds since 10.59.0 (server-utils → meriyah not fully traced by nft) #23034: meriyah missing from Next standalone output
• @sentry/sveltekit: server entry statically re-exports the Vite plugin, pulling @babel/core into the runtime module graph #23243: SvelteKit pulls in @babel/core
• @sentry/nuxt 11: CommonJS packages inlined for build-time instrumentation break in the Nitro bundle #24775: Nuxt/Nitro inlining breaks
• [SvelteKit 3] Sentry 11.8 build-time instrumentation breaks PostgreSQL bundling in Azure Functions #25470: SvelteKit 3 / Azure bundling of pg

Users usually find these, often in production deploys, and nothing stops the same shape from coming back. dev-packages/bundler-tests only covers a basic fixture and does not check what a runtime entry may reach.

Proposal

1. Add a runtime import-graph guard in CI. For every server runtime entry, resolve the full import graph (esbuild metafile and/or @vercel/nft, which matches what Next standalone and similar tools trace). Fail if the graph reaches build-only code, e.g. @sentry/bundler-plugins, oxc-parser, @sentry/server-utils/orchestrion/bundler/*, vite, webpack, rollup, @babel/* or *.wasm. The entries to check:

   • @sentry/node (.)
   • each meta-framework's server entry (nextjs, nuxt, sveltekit, astro, react-router, remix, tanstackstart, solidstart)
   • @sentry/cloudflare, @sentry/bun, @sentry/deno and @sentry/vercel-edge

   The set of runtime entries is small and enumerable, so the guard is cheap to maintain and turns this class of regressions into a PR-time failure.

2. Fix the violations the guard finds. One known case is @sentry/astro: its . export (node condition → index.server) is both the Astro integration (export default sentryAstro, used in astro.config) and the server runtime SDK. Through packages/astro/src/integration/index.ts, the runtime entry therefore imports @sentry/bundler-plugins/vite, @sentry/server-utils/orchestrion/vite, fs and createRequire. Fixing it needs a separate config entry (or an equivalent split), so it needs a decision on how to stay backwards compatible with import sentry from '@sentry/astro' in astro.config.

Out of scope here: changing package dependencies, e.g. #24849 (@sentry/node depending on @sentry/bundler-plugins). That affects install footprint, not what ends up in bundles, and changing it would be breaking.