@sentry/cloudflare/vite: Upload source maps from the Vite plugin

Description

@sentry/cloudflare/vite instruments the Worker, but it does not upload source maps. To get readable stack traces today, users add a second plugin themselves:

// vite.config.ts
import { cloudflare } from '@cloudflare/vite-plugin';
import { sentryCloudflareVitePlugin } from '@sentry/cloudflare/vite';
import { sentryVitePlugin } from '@sentry/vite-plugin';
import { defineConfig } from 'vite';

export default defineConfig({
  build: { sourcemap: true },
  plugins: [
    cloudflare(),
    sentryCloudflareVitePlugin(),
    sentryVitePlugin({ org: '...', project: '...', authToken: process.env.SENTRY_AUTH_TOKEN }),
  ],
});

Two Sentry plugins for one Worker is easy to get wrong, and it leaves every Cloudflare-specific detail (below) to the user.

Proposal: let sentryCloudflareVitePlugin upload source maps itself, through an option:

sentryCloudflareVitePlugin({
  sourceMapsUploadOptions: {
    org: '...',
    project: '...',
    authToken: process.env.SENTRY_AUTH_TOKEN,
  },
});

The plugin composes sentryVitePlugin from @sentry/bundler-plugins/vite, the same way @sentry/sveltekit, @sentry/solidstart, @sentry/nuxt, @sentry/react-router and @sentry/astro already do (see packages/sveltekit/src/vite/sourceMaps.ts). Upload stays opt-in: without an auth token, org and project, nothing is uploaded.

Cloudflare specifics the plugin should handle

• Enable source maps for the Worker build. The build needs build.sourcemap, which many Cloudflare templates leave off. The plugin should turn it on (or warn) for the server environment.
• Do not ship the maps. A Worker has a size limit, and the maps would be public. The maps must not end up in the deployed bundle or in the assets directory, so sourcemaps.filesToDeleteAfterUpload (or the equivalent) must cover the generated server output.
• Multiple Vite environments. A Cloudflare build produces the Worker environment plus client assets (and framework builds such as vinext add rsc and ssr). The plugin should upload the ones that belong to this app and skip the rest.
• Release must match the runtime release. packages/cloudflare/src/options.ts resolves the release as: user option, then SENTRY_RELEASE, then the CF_VERSION_METADATA.id binding. The version metadata id only exists after the deploy, so a build-time upload under a different release name does not symbolicate. The plugin should document this and make the working combination easy, for example by requiring an explicit release in both places when CF_VERSION_METADATA is used.
• Wrangler's own upload_source_maps. That option sends maps to Cloudflare, not to Sentry. The docs should say the two are independent, so users do not think one replaces the other.
• Keep the upload out of the runtime graph. @sentry/cli and the bundler plugin must not be reachable from the Worker bundle. See #23495, where a static re-export pulled them into the server graph.

Scope

• sourceMapsUploadOptions on SentryCloudflareVitePluginOptions, plus the composed sentryVitePlugin.
• @sentry/bundler-plugins as a dependency of @sentry/cloudflare (already used by the framework SDKs listed above).
• Tests: upload is off without credentials, the returned plugin list contains the upload plugin when configured, and the generated maps are deleted after upload.
• Docs: a Cloudflare source maps section, including the release caveat.

Notes

• Related but different: #19213 (OpenNext worker.js source maps) and #20051 (Nuxt on Cloudflare, js_invalid_sourcemap_location). Both are about apps built by another framework toolchain, not about this plugin.