fix(cloudflare): Fork the isolation scope for Durable Object methods

[JPeer264]

This came up while trying to reuse one client instead of creating new clients per request. We had the logic with currentClient ? withScope : withIsolationScope to identify if a new isolation scope should be created or not. The main issue is that if the client exists we use withScope, which actually reuses the wrong isolation scope instead - this results in leaking data in one request into the next. The scopes are independent of clients, and will also be in the future, as the goal is to only have 1 client in the future for multiple requests.

It seems this already came up a long time ago for Nuxt where it got fixed:

sentry-javascript/packages/nuxt/src/runtime/plugins/sentry-cloudflare.server.ts

Lines 81 to 83 in 87db4d2

	const newIsolationScope =
	isolationScope === getDefaultIsolationScope() ? isolationScope.clone() : isolationScope;

(so in theory this could be removed, but keeping this wouldn't harm unless we're 100% sure that this can go away cc @s1gr1d)

---

Clanker description

setUser/setTag write to the isolation scope, and a Durable Object keeps that scope across invocations. Methods only forked the current scope while no client was bound — but disposing a client at the invocation boundary does not unbind it, so from the second invocation onward the still-assigned client made every entry point look reentrant and skip its fork. Data from one invocation thus reappeared on the next, and a user identity could attach itself to an unrelated event.

An instrumented handler is either an invocation's entry point or reentrant (a DO method calling its own fetch, an RPC method reaching a sibling). Only the entry point may fork; a bound client can't distinguish the two, so withInvocationIsolationScope records the fact directly as a marker in SDK processing metadata (stripped before send). The stack fallback doesn't clone, so its scope is left unmarked rather than making every later entry point look reentrant. Forking loses nothing — it clones, inheriting enclosing request data — and matches how the Worker fetch path already behaves.

Covered by integration tests against a real Durable Object (consecutive invocations, a nested direct call, a nested call onto the instrumented fetch) and unit tests for the reentrancy logic plus the instrumentWorkerEntrypoint RPC and webSocketMessage/alarm consumers.