Preserve AbortSignal across SDK fetch adapters

[betegon]

Follow-up to evaluate after the object-client DX change merges. Part of v1.0.0.

Observed failure

The SDK dispatches fetch(request), carrying the caller's signal in request.signal. The CLI adapter's executeAttempt reads only init?.signal for timeout composition and abort classification. Since init is absent on this path, the native fetch receives a replacement signal that has lost the caller's cancellation.

A mocked transport probe with an already-aborted caller signal reproduced this for both standalone and bound SDK operations. The SDK preserved the original signal; the consumer adapter dropped it. This is not introduced by the object-client change.

SDK scope and ownership

Track the SDK's fetch-adapter contract here and determine what can be shared. The concrete adapter fix belongs in getsentry/cli; an SDK-only change cannot guarantee cancellation if a consumer replaces the signal.

Consider documentation and contract tests first. Add a reusable SDK utility only if it provides useful composition across consumers, keeping credential refresh, consumer timeouts, and application error policy with their owners.

Acceptance criteria

• Document that injected fetch implementations receive a native Request and must preserve its signal, body, method, and headers while respecting explicit RequestInit overrides.
• Link the CLI correction and verify both fetch(Request) and fetch(url, init) paths.
• Test already-aborted and in-flight cancellation, composition with internal timeouts, and preventing additional retry attempts after caller cancellation.
• Keep caller cancellation distinguishable from a consumer-generated timeout and retain the original abort reason where supported.

Related: opt-in retries #92. Any shared retry helper must satisfy this cancellation contract; this issue does not require adding retries.