tcp: a peer still sending after its handler let go no longer holds the reactor's recv buffers

[MDA2AV]

A peer that kept sending after its connection's handler let go could take every recv buffer in the reactor's shared group, so the reactor's other connections stopped receiving until that peer closed or the read timeout ended it.

DecRef sends a still-connected peer a FIN and keeps the read side open until the peer closes, bounded by ReadTimeoutMs (60 s by default). From then on nobody reads the connection, but OnTcpRecvCompletionShared still queued each delivery on it with Complete, and each one held a buffer of the reactor-wide group. RecvQueueEntries and RecvSlots are both 4096 by default, so one such peer could hold the whole group. Every other connection's recv then parked on -ENOBUFS, and RearmStarvedRecvs waits for a buffer to come back, which never happened. #257 accepted that one connection can stall the group while its handler isn't reading yet. A let-go connection is never read. In incremental mode the queued deliveries fill the connection's own ring and park its recv, so the peer's close goes unseen and the connection keeps its fd and buffer group until the read timeout. That is bounded, not a leak or growth, but it outlives the peer.

Once HandlerReleased, both recv completions hand the delivery's buffer straight back instead of queueing it. Shared mode returns it to the group. Incremental mode applies the same return a reader would have made (ApplyReturnIncremental). The multishot stays armed, so the peer's close is still seen and still ends the connection, and ReadTimeoutMs still bounds a peer that never closes. No new state: HandlerReleased reads the refcount the sweep already reads for the deferred FIN. Deliveries already queued when the handler let go are still returned at teardown, as before. The check adds a load and a branch to every recv completion and hasn't been benchmarked yet.

Tests

New, in HardeningTests:

• tcp/exit: a peer still sending after its handler let go does not starve the reactor's other connections
• tcp/exit: control: a peer lingering silently after its handler let go leaves the others served
• tcp/exit: a peer that overfills its let-go connection's ring is still seen to close (incremental)

Each lingering peer is served once, and reads its handler's FIN before it sends, so its handler has let go. The shared server has 16 buffers of 64 bytes and a queue of 64, so only the group can run out. The peer sends 2 KiB, then a second client asks for a response. In the incremental test each connection gets a ring of 4 × 1 KiB. Eight peers each send 8 KiB and close, and the test counts the server's open descriptors. Removing either half of the fix fails only that half's test.

	main	this PR
next connection while a let-go peer sends 2 KiB	never answered (3 of 3)	200 (5 of 5)
control: the let-go peer stays silent	200	200
incremental: connections still open after 8 peers sent 8 KiB and closed	8 of 8 (3 of 3)	0 (13 of 14 runs; 2 once)

All suites pass: Unit 63, E2E 255, Tls 155, Chaos 47 (and File 4).

Bench: this adds one load and a branch to every TCP recv completion, in both modes. A before/after run will follow here once the box is quiet; other suites are running on it now.

[MDA2AV]

Bench, before/after:

sample	main	this PR
Tcp/Raw	868,177 req/s, 2.33 us/req (2.18-2.34)	872,922 req/s, 2.32 us/req (2.29-2.47)

No measurable cost: main's own three rounds spread 7% on this sample, and this PR sits in that range.

Method: bench/any.sh (wrk), 2 reactors, 64 connections, 8 threads, 10 s per cell, server pinned to P-cores 0-7,10-15, all cells saturated. 3 rounds, each branch run right after main (f298af0) in the same round, so drift lands on both. Median (min-max) of the 3.