test(nextjs): Run nextjs-16 on Bun, Deno and Cloudflare

nextjs-16 gets variants for Bun, Deno and Cloudflare Workers (OpenNext) and
replaces `nextjs-16-bun` and `nextjs-16-cf-workers`. Each of them sets its
`runtime` and runs the production tests. Bun, Cloudflare and Cloudflare with
the latest Next.js are required jobs, as the two old apps were. Deno is
optional.

- Bun and Deno run `next start` on the same build as Node.js. The server
  config adds the integrations of `@sentry/bun` and `@sentry/deno` that
  replace the Node.js instrumentation these runtimes do not trigger. The
  e2e README now describes this, and that `variants` run as required jobs.
- Cloudflare builds with `opennextjs-cloudflare` and wraps the Worker in
  `worker.ts` with `withSentry` from `@sentry/nextjs/cloudflare`.
  `pg-cloudflare` is in `serverExternalPackages`, because OpenNext copies the
  `workerd` build of a package only when that list has the package.
- The app does not depend on `@opentelemetry/api` directly, because the
  OpenNext middleware bundle can not load an installed copy.
  `/api/otel-context` uses the copy of Next.js.
- The mock AI server runs in the Playwright global setup instead of the app,
  because a Worker can not start a `node:http` server. Thus the OpenAI test
  runs on every runtime.
- New tests check on every runtime that a log of a route handler arrives in
  the trace of the request, that the outgoing `baggage` carries the trace id,
  the sampling decision and the environment, and that a continued request
  has one segment.
- Tests branch on `getRuntime()` where the runtimes differ (segment origin
  and attributes, middleware spans in the request segment of the Worker,
  fetch span attributes). They skip what a runtime can not do: Node.js
  runtime metrics on Workers, and `pg` spans on Bun and Workers, which have
  no runtime module hook.

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

Author: JPeer264

dev-packages/e2e-tests/README.md

@@ -138,8 +138,9 @@ Apps like `cloudflare-workers-send-to-sentry` deploy the built app as a real Wor
 
 ## Runtime variants (Bun, Deno, Cloudflare)
 
-To test a framework on a runtime other than Node.js, add an `optionalVariants` entry to the existing test app instead of
-creating a new app. `react-router-8-framework` is the reference setup.
+To test a framework on a runtime other than Node.js, add a variant to the existing test app instead of creating a new
+app: `variants` run as required CI jobs, `optionalVariants` as optional ones. `react-router-8-framework` is the
+reference setup.
 
 - **`runtime`**: set `"runtime": "bun"`, `"deno"` or `"cloudflare"` on the variant. For such a variant, CI installs Bun
   or Deno, and the runner and CI set the `RUNTIME` env var for the build and the assert command. Without `runtime`,
@@ -152,7 +153,10 @@ creating a new app. `react-router-8-framework` is the reference setup.
 - **SDK per runtime**: each runtime inits its own SDK, the way a user of that runtime would: Node the framework SDK
   (`instrument.mjs`), Bun `@sentry/bun` (`instrument.bun.mjs`), Deno `@sentry/deno` (`instrument.deno.mjs`) and
   Cloudflare `@sentry/cloudflare`. The framework SDK only provides the framework wrappers on the other runtimes, so
-  values that come from its `init()` (`sdk.name`, default integrations) are Node-only.
+  values that come from its `init()` (`sdk.name`, default integrations) are Node-only. Next.js is different: it loads
+  `instrumentation.ts` on every runtime, so `nextjs-16` calls `init()` of `@sentry/nextjs` on Bun and Deno too, and
+  adds the integrations of `@sentry/bun` or `@sentry/deno` that replace the Node instrumentation those runtimes do not
+  trigger.
 - **Start commands**: `playwright.config.mjs` selects the start command with `getRuntime()`. Bun and Deno use the same build
   as Node and only change the start command, for example
   `bun --bun --preload ./instrument.bun.mjs ./node_modules/@react-router/serve/bin.cjs ./build/server/index.js` and
@@ -167,7 +171,9 @@ creating a new app. `react-router-8-framework` is the reference setup.
   separate file (for example `workers/app.ts`) and exports a plain handler: the Sentry plugin wraps it with
   `withSentry` and reads the init options from `instrument.server.ts` next to the entry. The start command runs
   `wrangler dev` on the build output. Code at module scope must not do I/O (for example open a database connection),
-  because workerd does not allow it.
+  because workerd does not allow it. `nextjs-16` has no Vite build: its Cloudflare variant builds with
+  `opennextjs-cloudflare build` and wraps the generated Worker in `worker.ts` with `withSentry` from
+  `@sentry/nextjs/cloudflare`.
 - **Runtime-specific files**: a file that has the runtime as a part of its name replaces the existing file without that
   part, for example `app/entry.server.cloudflare.tsx` replaces `app/entry.server.tsx` and `vite.cloudflare.config.ts`
   replaces `vite.config.ts`. For a variant with `runtime`, the runner copies these files over the others in the