fix(cloudflare): Enforce flush timeout across Workflow lifecycle - #24483

Cloudflare was reporting that Sentry-owned waitUntil() tasks remained pending after instrumented Workflows had completed. The configured flush(2000) timeout did not fully bound the work associated with a flush.

Three separate lifecycle gaps contributed to the warning.

Transport requests survived a timed-out drain

IsolatedPromiseBuffer.drain(timeout) returned false when its timer expired, but the request producers it had started continued running. A slow or stalled fetch therefore remained attached to the invocation after Sentry reported that its flush had timed out.

Each drain now owns an AbortController. When that drain expires, it aborts only the requests started by that drain. makeCloudflareTransport combines the drain signal with any caller-provided fetchOptions.signal, removes both listeners when the request settles, and keeps overlapping drains isolated so one timeout cannot abort another drain's requests.

Workflow steps inherited the previous step's flush point

Cached Cloudflare clients reuse the Workflow run's isolation scope across step RPC invocations. The first boundary flush marked that scope's flushPointReached state as true, and later steps inherited it. Envelopes created by those later steps were consequently treated as post-invocation telemetry and registered additional eager waitUntil(transport.flush(2000)) drains even though every step already performs its own boundary flush.

The wrapped step callback now resets flushPointReached before it captures telemetry. This makes each Workflow step begin before its own flush point, while retaining eager delivery for telemetry that is genuinely created after that step's boundary flush.

Flush-lock finalization was outside the timeout

CloudflareClient.flush(timeout) awaited flushLock.finalize() before applying timeout to pending spans and the transport. A user waitUntil task that never settled could therefore keep the Sentry flush pending indefinitely. The pending-span and transport phases could also each receive the original timeout instead of the time remaining from one overall deadline.

flush() now computes one deadline and passes the remaining budget through flush-lock finalization, pending-span completion, and the transport drain. It returns false without beginning a later phase when the budget has already been exhausted.

Validation

Each failure has focused red/green regression coverage:

• a timed-out drain aborts its request, preserves a caller signal, and does not abort requests owned by an overlapping drain;
• every Workflow step starts with its own unreached flush point; and
• a never-settling flush lock causes flush(timeout) to return false within the deadline.

The production reproduction uses 100 trivial step.do() calls and an HTTP transport that delays every response for 120 seconds. The transport fix alone removed the warnings with cacheClient: false, but warnings remained on the current cached-client path. Disabling eager envelope delivery isolated the remaining behavior to the inherited Workflow flush point. With eager delivery enabled and both lifecycle fixes applied, 20/20 deployed Workflow instances completed with zero matching waitUntil() warnings in Cloudflare Observability.

The complete @sentry/cloudflare suite passes (955/955), along with package lint, build, and typecheck.

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).
• Link an issue if there is one related to your pull request. If no issue is linked, one will be auto-generated and linked.

Closes #24482