Follow-ups from #808: std h2c conns get no GOAWAY and outlive the drain, a pool-wait bound test that passes on main, cost wording

[FumingPower3925]

Follow-ups from the round-1 review of #808 (celeris#759), none blocking; the blocking ones (new connections served during the wait, streams above a GOAWAY's last-stream-id served, response DATA waiting for WINDOW_UPDATE cut, the no-deadline floor) are fixed in #808 itself, and so is the stale engine.Engine.Shutdown doc.

1. std never sends an h2c connection GOAWAY, and such a connection outlives the drain. waitH2Streams (engine/std/engine.go) polls the stream count under drainCtx; nothing closes or GOAWAYs the hijacked h2c conn, so it keeps accepting new streams during the wait and after Shutdown has returned and the OnShutdown hooks have run. Under steady h2c traffic the count-based wait can use the whole budget. The part after Shutdown returns predates fix(epoll, iouring, std): graceful shutdown waits for the HTTP/2 streams on the shared worker pool, and std for its h2c streams (celeris#759) #808. Round-1 review probe on std: a stream (5) opened after "Shutdown returned after 2.005s" was served.
2. TestShutdownH2PoolWaitIsBounded passes on main and allows budget + 3 s (shutdown_h2_pool_linux_test.go, bound = 3 * time.Second): it only rules out an unbounded wait. A lower bound (the handler is still held when Start returns, at no less than the budget) and a tighter upper one would pin the wait itself.
3. Nit: the cost claim holds to about ±5 %. BenchmarkBridgeServeHTTP reported the head, which adds work, as significantly faster (-4 % to -5.5 %), so it has a bias at that level, and BenchmarkPoolDispatch's spread is ±11-22 %. The body should say "within ±5 %" rather than "no measurable cost". The GOAWAY wire test catches the m1 mutant on io_uring only some of the time (the drain-order test catches it on every native engine).

[FumingPower3925]

More follow-ups, from CodeRabbit's review of #808's rebased head 3f75937 and from the merge-train read of it against main c8400ba (none blocking; the one real defect CodeRabbit found, a refused stream touched after it went back to the pool, is fixed in #808 itself, 0df4ac2):

4. std's drain serves an h2c stream that opens while it waits (CodeRabbit, engine/std/engine.go drain): nothing gates Bridge.ServeHTTP for ProtoMajor == 2 once the drain has begun, so a stream opened on an existing h2c conn during waitH2Streams is served and counted, and under steady h2c traffic the wait can use the whole budget. Same root as item 1 (no GOAWAY on std); a gate set before server.Shutdown, refusing new HTTP/2 requests (503, or better a GOAWAY/REFUSED_STREAM once item 1 is done) while the counted handlers finish, would close it.
5. TestShutdownWaitsForFlowControlledH2Response/*/sync synchronises on a 300 ms sleep (CodeRabbit, shutdown_h2_pool_linux_test.go): the sync route's shutdown begins 300 ms after the request is written, assumed to be after the handler ran. On a slow runner the GOAWAY can name last-stream-id 0, stream 1 is refused, and the test fails for the wrong reason. Wait for stream 1's first DATA frame (the reader goroutine can signal it) instead.
6. Server.Shutdown's doc says the HTTP/2 wait and the send drain last "no longer than [Config.WriteTimeout]" (server.go): that holds only while WriteTimeout is set; -1 resolves to 0 and neither sendDrainWait (epoll) nor h2PoolSettled (io_uring) caps then, as docs#81 (7092028) says for the send drain and docs#82 now says for the HTTP/2 wait.
7. The shutdown GOAWAY can be refused on back-pressure 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, unchecked (h2PoolSettled, epoll and io_uring): GoAway writes through cs.writeFn, which 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 refuses a write when the conn's backlog is over its cap (64 MiB for HTTP/2) and sets writeRefused. h2PoolSettled does not look at it, so the GOAWAY is lost and the conn is closed only at its next write-queue drain (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 rule). Harmless as it stands, but untested; checking writeRefused after GoAway and closing as the write-queue drain does would make it explicit.

[FumingPower3925]

From CodeRabbit's review of goceleris/docs#82 (this PR's docs), none blocking:

8. The graceful-shutdown page's measured paragraph names no run record (docs src/content/docs/graceful-shutdown.md, "(Measured on each engine ..."): the h2c result fix(epoll, iouring, std): graceful shutdown waits for the HTTP/2 streams on the shared worker pool, and std for its h2c streams (celeris#759) #808 added ("got its response on every engine, with the hooks run after the handler") and the byte counts from docs#81 / celeris#760 (2,634,240 of 3,145,849 bytes before v1.6.0; 2,634,119 of 3,145,728 on a CI runner) say neither which run nor which machine/architecture. Link the run (a CI run, or the lane evidence with its machine) or drop the machine-specific counts.
9. The send drain's sentence on the same page leaves the floor's precedence open (docs, "It never sends for less than 250 ms, nor, while Config.WriteTimeout is set, for longer than that"): with a positive WriteTimeout below 250 ms the floor wins (sendDrainWait takes the later end), as docs#82 now says for the HTTP/2 wait; the send drain's sentence could say so too.