tests: pin the PipeReader contract and the ring buffers behind it

[MDA2AV]

Answers #226 — see the investigation comment for the full write-up. Tests only; no src/ changes, because both halves of the question turned out to be working.

What had no coverage

TcpConnectionPipeReader is the zero-copy reader: it hands out ring memory rather than copies. Both of the things #226 asks about fail silently when they are wrong.

Get examined wrong and ReadAsync hands back the same bytes forever, so an ordinary "read until I have a whole frame" loop spins hot. Get consumed wrong and either the buffer never returns to the group, or it returns while the caller is still holding a slice of it.

The three tests

examined-to-the-end parks the next read instead of respinning it. Consume nothing, examine everything, read again — the read must not come back until there are new bytes, and when they arrive it must still carry the unconsumed prefix. AB then C reads back as ABC, not C.

Consuming part of one recv leaves the rest readable. HEAD|BODY in a single recv, consume five bytes, read again: BODY comes back from what is already held, without parking.

This is the case AdvanceTo rebases offsets for, and I checked the assumption underneath it because the comment there is surprising enough to be worth confirming:

seq = new ReadOnlySequence<byte>(segA /* RunningIndex 4096 */, 30, segB, 50);

seq.Length           = 120
seq.GetOffset(Start) = 4126     <- not 0
seq.GetOffset(End)   = 4246

GetOffset measures from the segment's RunningIndex, not from the sequence's logical start. So the - startOffset rebase is load-bearing: without it the held-byte counter goes negative and the next read parks forever on bytes that already arrived — the hang the existing comment describes.

Recv buffers go back to the ring as consumption passes them. 2,000 request/response round trips through an eight-slot buffer group. If a consumed buffer did not return, the group is exhausted within a handful of messages.

Non-vacuous — deleting the ReturnBuffer call in AdvanceTo:

FAIL  pipereader: recv buffers go back to the ring as consumption passes them:
      Unable to read data from the transport connection: Connection timed out.

E2E 188 passed, 0 failed.

One harness wrinkle, handled

Every handler here ignores a connection that sends nothing and then closes. TestServer proves a port is listening by connecting a TcpClient and dropping it, so every server serves one probe that is not the test's.

On a PipeReader that is a real trap rather than a nuisance: the probe's first read reports IsEmpty && IsCompleted, which is exactly the shape a finished stream has. My first draft of the buffer test was filled in by the probe and reported served 0 before the test's own connection had said a word.

Not in this PR

Two things the investigation turned up that need source changes, deliberately left out:

• TcpConnectionDualPipe has no IAsyncDisposable. DrainRecv() at recycle drains the connection's SPSC ring only, so slices already pulled into the reader's chain come back only via Complete(). That makes "Complete the reader before DecRef" load-bearing and unenforced — sharper in incremental mode, where recycle AlignedFrees BufSlab wholesale and the generation guard drops a late return. The TLS dual pipe already has a disposal; this one is two properties.
• TlsProloguePipeReader reports IsCompleted going back to false after a partial consume once the peer is gone. Already pinned by the pending test at PrologueReaderTests.cs:145, so not re-filed.

On closing #226

Left without a closing keyword. The literal questions are answered and now pinned, but the dual-pipe disposal gap above came out of the same investigation, so whether to close it or keep it open for that is your call.