fix(io): stop re-fetching bytes the open already has

[superuser404notfound]

Follow-up to #281, from measuring rather than reasoning. aetherctl against a Range-logging origin, four MP4 layouts, all sized above the 32 MB range so their tails lie outside the first window.

Three defects, all the same shape

A range that finished delivering was fetched again. A completed range clears activeTask exactly as a dropped one does, and the no-connection branch reconnected at the READ position regardless, which resets winStart and drops everything still resident. The parse pass is precisely the consumer this bites: it reads one 256 KB AVIO buffer at a time while the transfer runs at line rate. A 764450 B trailing moov cost three connections and 1506918 delivered bytes, 1.97x its own size, each reconnect landing exactly one AVIO buffer further on. The branch already excluded the hard-cap end for this reason; the reasoning was never extended to a range that simply finished. Serving what is in hand first also revives the #220 frontier refill, which could not run while this branch preempted it on every completed range.

A read at EOF opened a connection for it. The EOF decision sat below that reconnect, so a position at exactly fileSize issued bytes=<fileSize>- and took an empty 206, whose reconnect reset winStart past the last byte and dropped the window the parse was still reading.

The parked window was cut from the wrong place. #281 parks at seek time from winStart, on the reasoning that the demuxer returns to the window's start. It returns to the FILE's start: landings of 48, 1161, 5752 here and 265159 in the field trace on #281. Those coincide only when the parse seeks away before reading anything. A fragmented MP4 reads 33 MB first, so the parked copy begins megabytes past everything the return asks for and covered nothing. The head is now collected as the data connection delivers it, which is the only point at which it can be: trimWindowLocked drops it as the parse moves forward.

Measured

Request counts, loopback:

layout	before	after
moov at end, 764450 B	5	3
fragmented, mfra at end	5	3
moov at end, 23337 B	2	2
faststart	2	2

Wall clock, same origin with 300 ms of latency per request (loopback cannot show an overlap):

layout	before	after
fragmented, mfra at end	1732 ms / 4 req	1219 ms / 3 req
moov at end, 764450 B	678 ms / 3 req	708 ms / 3 req
moov at end, 23337 B	390 ms / 2 req	385 ms / 2 req
faststart	420 ms / 2 req	420 ms / 2 req

Tests

Three new, each verified red against the old behaviour: a completed range is read out of the window, a read at EOF opens nothing, and the return to the head survives a parse that read past the window's start. 1435 green.

Kept on the argument rather than on evidence

The parked window stays. It covers a return to a mid-file offset, which the retained head cannot, and it did not fire on any layout measured here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HX5zV3Fcf7Nzq4DYGdXvQE

[superuser404notfound]

Both points I had left on an argument rather than on a measurement are now measured, and one of them did not survive.

The parked window is gone

It served no read on any of six container layouts. The demuxer returns to the head of the FILE in every one of them, which the retained head covers, so the park was carrying a premise the measurement contradicts plus up to 4 MB of transient footprint next to the copy that actually answers. Request counts are unchanged by the removal on all six.

layout	requests	what answered
faststart.mp4	2	nothing
moovend.mp4	2	tail prefetch (trailing moov, 23337 B)
bigmoov_end.mp4	3	retained head (trailing moov, 764450 B, too big to fit the suffix)
frag.mp4	3	tail prefetch (mfra) + retained head
cues_end.mkv	2	nothing
cues_front.mkv	2	nothing

Worth recording separately: matroska does not read its Cues at open, wherever they sit. The speculative fetch is spent on both MKV layouts.

The speculative suffix fetch stays, and now there is a number for it

It pays off on two of the six, so the question was whether the other four are paying for them. Five runs per point at 250 KB/s with 300 ms of latency, spread under 30 ms:

layout	with	without	delta
faststart.mp4	1587 ms	1335 ms	+252 ms
cues_end.mkv	1590 ms	1350 ms	+240 ms
moovend.mp4	1716 ms	2076 ms	-360 ms

The cost is exactly the link time of 64 KB (64 KB / 250 KB/s = 256 ms). The benefit is one round trip plus the sequential tail fetch it replaces. They are equal at about 2 Mbit/s, which cannot stream the material this engine opens; at 10 Mbit/s the cost is 51 ms against a round trip the #281 field trace measured at 438 ms. Keeping it.

1435 tests green.