Follow-ups from #805: the memory bound after the per-request cap, epoll's closing-conn reap by read time, no deterministic H2 refusal test, io_uring's dormant WRITEV path, body nits

[FumingPower3925]

Follow-ups from the round-1 review of #805 (celeris#761, celeris#802), none blocking. The blocking findings (pooled bodies reused before they were sent, the io_uring closing drain's 5 s cut, a streamed response cut at the cap, a backlog test that could not fail, CI time) are fixed in #805 itself; so are two minors: a failed read of a staged file now closes the conn (writeRefused) instead of leaving a header block with no body, and the gated TestWriteBufBackpressureClosesSlowConsumer asserts the server's close, not the client's view of the orphaned send queue.

1. The memory bound moved; state or track it. An HTTP/2 connection may queue 64 MiB before a write is refused (16 times the H1 limit), and a peer that grants large windows and stops reading can pin that much per connection (maxPendingBytesH2, maxSendQueueBytesH2). A slow reader of a large HTTP/1 response holds a copy of the unsent tail (the flush copies the remainder into writeBuf). c.File responses pipelined behind one another are read whole into writeBuf by unstage, on the loop thread, with no cap check in makeSendFileFn (the case already existed through bufferedFileFallback). And a StreamWriter used without Detach on epoll or io_uring is buffered whole until its handler returns (Flush is a no-op on the H1 adapter): since fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805 it is delivered however large it is, where it was cut at 4 MiB, but its memory is the whole response. The docs' streaming page says "Flush guarantees the bytes are on the wire", which is not true there.
2. epoll reaps a conn left to closeWhenFlushed by ReadTimeout/IdleTimeout measured from the last read. lastActivity is stamped only by reads (engine/epoll/loop.go, drainRead), and checkTimeouts gives a non-dirty conn ReadTimeout, so a large response that a client reads steadily for longer than ReadTimeout (60 s by default) is cut. It predates fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805 but is now reachable, since responses over 4 MiB are delivered. (fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805 makes io_uring's closing drain restart its clock on send progress.)
3. The HTTP/2 parts of fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805's fix are caught only now and then. Neither the 64 MiB HTTP/2 cap nor the pendingBytes resync after the H2 write-queue flush has a deterministic test: in review, a mutant of each was missed in at least one of two TestLargeResponseIsDeliveredH2 runs, and the resync mutant's one failure was a 5 s stall with the connection open, so the H2 refused-write close path (closeWhenFlushed from the H2 queue loop) has no test. (On the real head the reviewer could not make an H2 refusal happen at all: a peer granting 2^31-1 windows and reading nothing for 2 s still got all 96 MiB.)
4. io_uring's WRITEV scatter-gather path is unreachable now. fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805 stops installing io_uring's zero-copy body writer (celeris#817): the kernel read the handler's buffer only at the next submit. bodyBuf, sendBody, iov and the WRITEV branches of flushSend and completeSend remain, dormant. Remove them, or bring the path back for bodies the engine may keep (a body backed by an immutable string, from c.String or c.HTML, or a buffer whose release the engine controls).
5. Nit (body wording): the round-1 body's per-cell H2 failing-first numbers were one sample of a timing-dependent result on epoll and adaptive (io_uring's fail every time); and its cost line inferred "well under the end-to-end noise floor" from a micro-benchmark, with the benchmark-tier row queued, not run, and the per-turn csPendingBytes resync in the H2 queue loop not measured.

[FumingPower3925]

From CodeRabbit's review of #805's round-2 head 052b5cc (three minor threads, two nitpicks), none blocking.

6. BenchmarkWriteHooks does not measure epoll's partial-writev branch (engine/epoll/loop.go, makeWriteBodyFn). The main-vs-head numbers for the zero-copy body are in fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805's Cost section (BenchmarkWriteHooks/zero-copy-body: 169.0 ns on main a73afb6, 172.5 / 171.7 ns on the head, 0 allocations in every arm). But the benchmark writes to /dev/null, which takes the whole iovec, so it never runs the branch where the kernel takes less and unstage copies the rest of the body into writeBuf, which can grow it (an allocation on the send path). Add a case that forces a short write (a socket with a small send buffer, or a pipe) and report it with -benchmem.
7. Three of fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805's tests use a sleep as synchronisation.
   • TestBackloggedPeerIsClosed (large_response_linux_test.go, time.Sleep(300 * time.Millisecond) before the client reads) is the one that can fail falsely. If the server has not reached the third request's back-pressure check within 300 ms, the client starts draining and all 4 responses can arrive, which the test reports as "the 4 MiB back-pressure cap did not apply".
   • In TestSplitBodyResponsesKeepTheConnection (2 ms, "the rest in a later read") and TestConcurrentResponsesOwnTheirBodies (100 ms after the /fill request) a late server only weakens the case; they do not fail falsely.
   • Wait on a server-side condition instead, with a generous deadline. No failure seen so far: CI on 052b5cc passed 19/19, and the trial merge of main 5cafb08 passed in a Linux container (linux/arm64, -race). Loaded runners have not been tried.
8. The negative control for TestPipelinedResponsesOwnTheirBodies: answered, no action. fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805's controls table (log 761/controls/052b5cc-variants-r2-unl.log) gives the failing leaves: main a73afb6 9/12, m2 (epoll stages the body for the flush again) 6/12, m3 (io_uring stages a zero-copy body again) 3/12, round-1 head 9/12, and the fix 0/12.
9. Remove skipIouringAsyncPipelined751 now that fix(iouring): an async handler's direct write waits for a ring SEND of the conn's earlier bytes (celeris#751) #800 is on main. The skip's comment says "Remove with fix(iouring): an async handler's direct write waits for a ring SEND of the conn's earlier bytes (celeris#751) #800", and fix(iouring): an async handler's direct write waits for a ring SEND of the conn's earlier bytes (celeris#751) #800 merged as 65d1755 (io_uring: an async handler's direct write goes out while a ring SEND of the previous response is still in flight, interleaving pipelined responses #751 closed). CodeRabbit notes that nothing in CI reports the skip. The trial merge of main 5cafb08 into 052b5cc was run with the skip made a no-op (one container, linux/arm64, unlimited memlock, -race, -count=5). TestPipelinedResponsesKeepTheirOrder and TestPipelinedResponsesOwnTheirBodies on io_uring: 30/30 leaves pass, async-route 5/5. TestBackloggedPeerIsClosed on io_uring: 15/15, async-route 5/5. Delete the helper and its two call sites.
10. Nit: TestWriteBufBackpressureClosesSlowConsumer stays gated on GOTEST_BACKPRESSURE=1, so CI skips it without a record. The gate predates fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805 (it is in a73afb6: "loopback TCP auto-tuning makes this non-deterministic on CI"). fix(epoll, iouring): send a large response whole, keep pipelined responses in order, never send a body the handler has given back (celeris#761, celeris#802, celeris#817) #805 ran it 3/3 in the CI shape. Give it a CELERIS_REQUIRE_* switch or a CI tally, or keep it as a documented manual test. (CodeRabbit's other point here, that the "3.5s" message is wrong, is withdrawn in its own text: 500 ms sleep + 3 s poll.)