[Vivek1898]

Fixes #26367

The problem

instrumentFetcher built the outgoing init with an object spread:

const mergedInit = { ...init, ...(headers ? { headers } : {}) };
return fetchFn(input, mergedInit);

Forwarding a request as stub.fetch(url, request) is a common Workers idiom, so init is often itself a Request. A Request's method, headers, body and the rest are prototype getters, not own enumerable properties, so the spread copied none of them. Behind an instrumented Durable Object namespace or service binding the call reached the object as a bare GET with no headers and no body, which broke WebSocket upgrades (Upgrade: websocket) and every forwarded POST. The same call works without Sentry.

The fix

Handle a Request-valued init the same way the existing input instanceof Request && init === undefined branch already handles a Request input: rebuild through the Request constructor, which reads method, headers and body by property access, then layer the tracing headers (which already include the request's own headers) on top. Plain-object init still goes through the existing spread path, so no other case changes.

Tests

Added two cases to instrumentFetcher.test.ts: a Request-valued init with a method, headers and body is forwarded intact with tracing headers added, and the same holds (minus tracing) when trace data is empty.