shared ring: no read backpressure, so the 65th unread recv completion closes the connection #535

This is documented: "Overflow drops the delivery that did not fit and closes the connection" (TcpOptions.cs:56-62). It's also deliberate: #257 made it an error rather than a clean end, and #371 set the default back to 64, knowing a handler can raise it. I'm filing it because of what that means in practice: a chatty client and a busy handler get a disconnect and lost data, where TCP would normally just slow the client down. It also counts completions, not bytes: 65 one-byte sends end a connection just as 65 full 32 KiB buffers do.

#431 fixed this for incremental mode by merging slices, which is exactly what that mode's own ring makes possible. Shared mode still has it, and raising RecvQueueEntries only trades it for more of #526.

Cause. A multishot recv stays armed whatever the handler is doing, and a full queue closes the connection (TcpConnection.Read.cs:271-293).

Reproduced at 0.25.482 (918ccc8), on x64 Linux 6.14, with RecvQueueEntries at its default 64: a handler busy for 300 ms in a RingTimer wait, and a client sending 100 one-byte messages 1 ms apart. The server logs recv queue overflow; closing connection, and conn.RecvOverflowed is true.

Fix options.

• Pause instead of closing. Cancel the recv when the queue is nearly full, and re-arm when the handler drains. This is the same change as the first option in shared ring: a few connections parked in a flush can drain the ring and stop every recv on the reactor #526.
• Merge small sends in the queue, as incremental mode does. In shared mode each completion has its own buffer, so this means copying them into one.

The same limit is filed on kron as MDA2AV/kron#37.