fix(io): a held connection ends on a pause, not on a parked producer (#377)

[Rasmusmart57]

The 5 s full-window end fires during playback rather than at a pause, which spends most of what heldSourceConnection is for. Measured on the origin from #377 rather than reasoned about.

What the field run showed

Apple TV 4K 3rd gen, tvOS 26.6, 6.75.0, one hour with the flag on and one hour without, same title, same evening, same edge, back to back:

                       held    pushed
connections             218      1055
429s                      0       157

The flag works. But 218 is not the one connection the design describes, and the reason is in the log:

[AVIOReader] pump held connection idle for 5s with 15MB ahead; ending it, will re-request at the frontier once the consumer drains

213 of those in the hour, and the viewer never paused once.

Why it fires

The constant's own comment names the case it is for:

This bounds the one dormant stretch the slack cannot: a consumer that has STOPPED. A paused viewer would otherwise hold a dormant flow for the length of the pause

But it infers "stopped" from a full window, and HLSSegmentProducer races ahead, fills the window, and parks with a full segment cache while the muxer works (parked=10s in the same capture). From the reader those are the same thing, so the pause fallback fires roughly every 17 seconds during ordinary playback.

That matters more here than the request count suggests. 218 connections against an origin that refuses requests are 218 chances to be refused, and 3.6 per minute is about 435 over a two hour film.

The change

The wait carries a deadline only while the consumer is actually paused. The signal is playIntentProvider, which HLSVideoEngine already owns and already hands to the producer; this plumbs the same closure to the reader alongside onNetworkPhaseChanged, engine → demuxer → reader. Nil means playing, so a reader nobody wires keeps today's behaviour.

A playing consumer with a full window issues no read and waits. No byte is on the wire, the socket buffer fills, and the sender stops itself, which is what an ffmpeg-based player does whenever its demuxer stops reading.

A paused one keeps a bound, at 300 s rather than 5. That is the unbounded stretch #310's worst episode came from, and it is the only one left once a parked producer is no longer read as a stopped one.

After

Same device, same source, ten minutes:

connections   6   (all in the open phase: header, index, tail)
pause ends    0
429s          0

The count stops growing once the file is open, which is the shape ffmpeg has against this same URL (three requests, one connection).

What is not measured

A multi-minute pause with the connection held. The 300 s bound is reasoned from #310's dose rather than measured, and if you would rather it were smaller, or driven by something other than wall clock, that is a number I have no evidence for. Arm B of the transport probe held a stream task on a closed window for 60 s on this device with 1 Hz canaries clean against both the origin and a neutral host, and arm C could not reproduce #220's mechanism there at all, but neither of those reaches a ten minute pause.

Happy to run whatever else against this origin.