feat(cloudflare): Auto-register Flue instrumentation in bundled workers - #24476

Flue is registered, not patched — `instrument()` writes into module-scope state —
so instrumenting it needs a reference to that module's own binding, and no
channel payload carries one. On Node the user supplies it by calling
`instrument()` themselves, which stays the only route there. In a bundled worker
there is no `node_modules` to resolve one from, so it is supplied at build time
instead.

Two halves, mirroring how Mastra reaches a worker:

- `flueIntegration()` registers the instrumentation when the `@flue/runtime`
  namespace is on the orchestrion marker, and no-ops when it is not. A
  `registrationOnly` orchestrion entry is what installs it on a bundler-only SDK:
  evaluating `@flue/runtime` registers the factory on the marker. That also keeps
  the integration reachable under `sideEffects: false`, which would otherwise let
  the bundler drop the module and the registration with it.
- `@sentry/cloudflare/vite` splices a static `@flue/runtime` import into Sentry's
  own Flue integration module and exposes the namespace on `providedModules`.

Two things the Mastra provider does not have to handle. `@flue/runtime` is
ESM-only, so `createRequire().resolve()` throws `ERR_PACKAGE_PATH_NOT_EXPORTED`
on it and the existence check goes through the ESM resolver. And the namespace is
exposed through a getter rather than assigned: the snippet is prepended to
Sentry's module, which the bundler may evaluate before `@flue/runtime` is
initialized, so assigning it stores `undefined` — the key lands on
`providedModules` with nothing behind it.

An app that also calls `instrument()` itself is unaffected: its own registration
wins and the integration swallows the resulting
`InstrumentationAlreadyInstalledError`.

Node is unchanged. `moduleInjectedTransforms` is wired into the bundler paths
only, and Sentry stays external in a Flue node build, so neither half applies
there and `flueIntegration()` installs as a no-op.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ation

The build-time presence check used `import.meta.resolve(spec, parentURL)`. The `parentURL`
argument is ignored without `--experimental-import-meta-resolve`, so the check resolved from
Sentry's own install rather than the app's, and it compiles to `undefined(...)` in this
package's CJS build, where it threw and fell through to a `createRequire` fallback that always
fails for an ESM-only package. Injection was therefore skipped outright on the CJS path and
wherever Sentry is not installed beneath the app.

It now resolves with `createRequire` from the Vite root and counts
`ERR_PACKAGE_PATH_NOT_EXPORTED` as a hit: `@flue/runtime` publishes no `require` condition on
any subpath, so that error means the package is present, while a missing one reports
`MODULE_NOT_FOUND`.

Also narrows the registration catch to `InstrumentationAlreadyInstalledError` so a changed
`instrument()` contract surfaces instead of becoming a debug log, bounds the supported range at
`<3.0.0`, drops the unused `flueModuleNames` export, and removes `flueIntegration()` from the
default integrations — it has no binding to read on Node, where registering stays a manual
`instrument(Sentry.createFlueInstrumentation())` call.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…try.init()`

Core calls `integration.setup()` unguarded, and Cloudflare runs `Sentry.init()` inside the
request wrapper, so rethrowing an unexpected `instrument()` failure would take down the
handler — and every later request, since the client is never cached.

A duplicate registration stays a debug log; anything else now warns that Flue spans will not
be recorded, which keeps the failure visible without making it fatal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>