tcp: reclaim recv buffers a reader or stream still holds at recycle

[MDA2AV]

Found while investigating #226. Proven, then fixed, then twice reviewed — both reviews found the fix itself was still wrong, in different ways.

The leak

TryGetItem is a dequeue. The moment a buffer is handed to a TcpConnectionPipeReader or a TcpConnectionStream, the connection's queue no longer has it — so DrainRecv at recycle walks straight past it, and the buffer comes back only if the holder is told to give it back.

Nothing obliged anyone to. TcpConnectionDualPipe is two properties with no disposal, unlike the TLS one, so a handler that returns early — the ordinary shape when a peer disconnects mid-request — takes its buffers with it. In shared mode those are slots out of the single group the whole reactor draws from, gone for the life of the process.

Measured before the fix, RecvSlots = 16, 64 sequential connections each stranding one buffer:

FAIL  recv buffers: a handler that never completes its reader does not strand them:
      expected [64], got [16]

Exactly the slot count, then the server could no longer receive at all.

The fix

The connection keeps one reference to whatever holds its dequeued buffers; Recycle claims it and asks for them back.

Cost: one reference store per holder construction — once per connection, not per request — and one exchange per recycle. Nothing on the recv or send path changed. The alternative, having the connection track outstanding ids itself, needs a record per dequeue and a clear per return on the hottest path in the runtime, to buy something that only matters at teardown. Wrong trade at these rates.

What review caught

Three ways the first version was still wrong. Each now has a test that fails without its fix.

Complete() de-registered unconditionally, so a reader holding nothing could evict a live holder — two readers on a connection, the first completed — putting the leak back silently, in the case nobody writes a test for.

Completing does not disarm a parked read. The awaiter stays armed, the next CQE resumes it, and the reader ingests after completion with nobody registered to reclaim. TlsConnectionDualPipe.DisposeAsync produces this shape on the kTLS RX column, and so does any read-timeout handler, since CancelPendingRead only sets a flag and never wakes a parked read.

Both fall to one decision: never de-register on Complete. The slot is cleared per connection life in Clear(), which reduces the invariant to "the last holder constructed in this life", and releasing twice is free because the chain is empty the second time.

TcpConnectionStream had the identical strand and was not covered at all. It holds the slice it is copying out and returns it only once drained, with no disposal of its own — and it is what Playground/Tls/SslStream runs on, where an aborted handshake is ordinary. Hence the shared IRecvBufferHolder rather than the reader-typed field I started with.

Both release paths are now terminal, so a holder used after its handler fails loudly instead of arming against the recycled connection's next tenant and handing out another peer's bytes. The stream needed _haveSnap cleared too: SpscRecvRing.Reset moves head/tail without clearing items, so a stale read could otherwise serve another tenant's bytes and double-return the id on drain.

I also corrected a claim I had written into a comment — that claiming the slot atomically makes a double return impossible. It does not: the holder still walks its own chain on Complete. What rules that out is the refcount protocol, same as everywhere else on the connection.

Tests

Five, in RecvBufferReclaimTests.cs, each driving 64 connections through a 16-slot group:

	fails without its fix as
a handler that never completes its reader	16/64
completing one reader does not de-register a live one	16/64
completing with a read still parked	16/64
a stream stopped mid-slice	16/64
control: completing the reader returns them	passes throughout

The control matters: it uses the same tiny group and passes on every variant, so the four failures above are the defect and not the group being drained by something else.

All suites green: E2E 190, Unit 43, Http 44, Tls 142, Chaos 47, File 4.

Bench

4 reactors, seven alternating pairs on Tcp/Pipe, the sample that uses the reader:

+0.7  -3.5  -3.9  +1.9  -2.0  -1.6  -2.4     mean -1.6%, five of seven negative

That sits inside the arm's own 6.7% run-to-run spread, and Tcp/Raw — which does not use the reader but does use the same (now one reference larger) connection object — came out +0.7% over three pairs. No code runs per request that did not before, so the lean is not attributable to any path in this diff. Reporting it rather than rounding it to zero.

Still open

TcpConnectionDualPipe still has no IAsyncDisposable. This PR makes forgetting to complete safe rather than making it hard, so the ergonomic half is worth doing separately.