feat(bun): Add @sentry/bun/light entry point without OpenTelemetry

[BYK]

Problem

@sentry/bun imports @sentry/node, which eagerly loads the entire OpenTelemetry stack and 29+ auto-instrumentation modules (Express, MongoDB, Redis, PostgreSQL, Kafka, Prisma, AI providers, etc.). For CLI tools and other non-server Bun applications, none of these instrumentations are relevant, yet they cost:

• ~150ms additional import time
• ~24MB in node_modules (36 @opentelemetry/* packages)

Measured Impact

Benchmarks from our Bun CLI project (getsentry/cli):

Import	Time	What Loads
@sentry/bun	~285ms	Full OTel stack + 29 auto-instrumentations (36 OTel packages)
@sentry/node-core/light	~130ms	Core SDK only, no OTel, AsyncLocalStorage for context

The ~155ms difference is entirely from OpenTelemetry packages that a CLI tool never uses. @sentry/bun adds only ~2ms on top of @sentry/node (it is a thin wrapper: BunClient, bunServerIntegration, makeFetchTransport).

Proposal

Add @sentry/bun/light that mirrors what @sentry/node-core/light does for Node:

1. Uses @sentry/node-core/light instead of @sentry/node — no OpenTelemetry dependency
2. Keeps Bun-specific niceties:
   • makeFetchTransport as default transport (uses global fetch())
   • runtime: { name: 'bun', version: Bun.version } in SDK metadata
   • SDK metadata tagged as "bun-light" (or similar)
3. No bunServerIntegration in defaults — it is for Bun.serve() which light-mode users (CLIs, scripts) likely do not need
4. Uses AsyncLocalStorage for context propagation (same as @sentry/node-core/light)

Usage

// Before (285ms):
import * as Sentry from "@sentry/bun";

// After (130ms):
import * as Sentry from "@sentry/bun/light";

All existing APIs (captureException, startSpan, setTag, metrics, logger, createConsolaReporter, etc.) would be available — just without the OTel auto-instrumentation overhead.

Current Workaround

We switched from @sentry/bun to @sentry/node-core/light directly (see getsentry/cli#474). This works but:

• Loses Bun-specific SDK metadata (runtime name shows as "node" instead of "bun")
• Does not use makeFetchTransport by default (falls back to Node's http module — works in Bun but is not native)
• Requires users to know about the internal package structure

A first-party @sentry/bun/light would be more ergonomic and keep Bun users within the expected SDK.

[linear-code]

JS-1965

[Lms24]

We could think about this because as it stands, Bun doesn't play well with OTel anyway. @isaacs what do you think?
So far I don't see much benefit besides slightly better startup performance (which again, if you bundle SDK code should be negligible). We should align this suggestion with our future plans for multi runtime support. I don't want to end up with multiple "light" API exports we'd potentially remove in the next major version again