ref(browser): Tree-shake span streaming out of error-only bundles - #23362

Stacked on #23361. Makes spanStreamingIntegration reachable only if span-creating code is reachable, so error-only apps drop the whole span streaming graph automatically — no __SENTRY_TRACING__ flag needed. No public API changes: Sentry.startSpan() from @sentry/browser works exactly as before.

Measured with size-limit (webpack, gzipped + minified):

Landing within 0.10 kB of the __SENTRY_TRACING__: false floor shows init's reference was the only thing retaining span streaming — there is no second reference to hunt down. Tracing users pay nothing extra.

This PR:

• Removes the spanStreamingIntegration() push from packages/browser/src/sdk.ts, along with the now-unused __SENTRY_TRACING__ declaration.
• Switches browser-facing packages to the @sentry/core/browser span-start APIs: browser-utils (performance/utils.ts, web-vitals/spans.ts), browser/src/integrations/fetchStreamPerformance.ts, svelte, sveltekit/src/client/load.ts, react-router/src/client/createClientInstrumentation.ts and effect/src/tracer.ts. Import names are unchanged.
• Calls _INTERNAL_ensureBrowserSpanStreaming(client) from browserTracingIntegration's afterAllSetup. Not load-bearing for correctness, but it means getIntegrationByName('SpanStreaming') and event.sdk.integrations are correct for errors captured before the first span starts.
• Drops the nextSpan re-export from packages/nextjs/src/client/index.ts, so the client keeps @sentry/react's span APIs.
• Adds the sdk/no-unguarded-span-apis oxlint rule, enabled once in .oxlintrc.base.json.
• Tightens the three init-only .size-limit.js entries to under 1 KB headroom.
• Adds packages/browser/test/tracing/spanStreamingWiring.test.ts, covering the wiring through init end-to-end.

Notes for review:

• Client.addIntegration runs setup() synchronously and is idempotent by name, so the afterSpanEnd listener is always registered before any span can end: a span can only end if it was started, and starting goes through a wrapper.
• The ensure call is in afterAllSetup, not setup. Client._setupIntegrations assigns this._integrations = setupIntegrations(...) after the setup loop, so an addIntegration from inside another integration's setup() gets clobbered in the index — the hooks would still fire, but the bookkeeping this step exists for would be lost.
• The lint rule is the only enforcement. Both variants share their names, so a stray plain import compiles fine and just stops sending spans. It has to land with the code it protects. It caught react-router/src/client/createClientInstrumentation.ts, which the original audit missed.
• effect/src/tracer.ts backs both the client and the server entry, so it uses the guarded variant too. On the server that's a no-op: ServerRuntimeClient already installs the integration eagerly and addIntegration dedupes by name. This is also why the rule's scope is expressed in code rather than as config globs — no files glob can say "this one file but not its siblings".
• The Cache Components overrides in nextjs/src/common/utils/nextSpan.ts are unreachable in the browser: isBuild() reads the server-only NEXT_PHASE env var, isUseCacheFunction() is a React server-reference check, and the browser export condition maps only to index.client.js (client components are SSR'd through the server entry). So the client needs no wrapper, and isBuild/isUseCacheFunction/SentryNonRecordingSpan drop out of the client bundle.
• Rejected alternatives: guarding core's createChildOrRootSpan (same size win, one call site — but it installs core's variant, which lacks the browser variant's 500 ms per-trace flush on afterSegmentSpanEnd, meaning real data loss on navigation and tab close; it also makes core's hottest path depend on more of the Client surface and charges Node a per-span cost for a browser-only benefit). Registering an AsyncContextStrategy from init() defeats its own purpose: the registration references the browser startSpan, so nothing tree-shakes.