fix(cloudflare): Don't hold Durable Object invocations open with the segment-end flush timer

[philipatkinson]

Since span streaming became the default (#22642) and segment-end flushing turned on for server runtimes (#23714), every root span end schedules setTimeout(flush, 500), sampled or not. #23714 relies on safeUnref to stop that timer holding a server open, but workerd timers have no unref(). A Durable Object invocation stays open until its pending timers fire, so every instrumented DO fetch, alarm, webSocketMessage and propagated RPC call runs about 500 ms longer. That time is billed as duration, and the pending timer also blocks hibernation. This happens at tracesSampleRate: 0 too.

The 500 ms delay comes from the browser (#19643): http.client spans stay open up to 300 ms waiting for resource timing, so they can end after their segment. Neither that nor the buffer-memory reason for flushing at segment end on servers (#23714) applies to Workers, where nothing waits for resource timing and spans are flushed at the end of every invocation.

The Cloudflare client now registers spanStreamingIntegration({ flushOnSegmentEnd: false }) unless the user supplies their own. The runtime doesn't need the timer: the boundary flush in wrapMethodWithSentry runs after the method span ends, and the cached client's eager drain covers spans that end after the flush point. This matches the existing _flushInterval: 0 for the log and metric buffers. Plain Worker handlers lose the timer too: it doesn't hold their requests open, so it cost them nothing, but withSentry's boundary flush already delivers their spans. In workerd, with the same change applied to 11.6.0, DO fetch and alarm wall time drops from about 505 ms to about 6 ms, and at tracesSampleRate: 1.0 the same span envelopes still arrive.

Fixes #25489