Grow channel receiving windows on demand

[AArnott]

Follow-up to #1123, continuing the work on #505.

A channel's receiving window is fixed when the channel is accepted, and that one number has to serve two irreconcilable purposes: bounding how much unread data a receiver may buffer, and bounding how much data a sender may keep in flight. On a link with real latency the second dominates — 1 MB over a 16 ms round trip caps a channel at ~62 MB/s regardless of how fast either end is — but raising the default to suit it makes every channel's worst case more expensive.

This PR lets a window grow after the fact, but only for the channels that demonstrably need it.

How growth is decided

Growth requires evidence from both ends, which is what keeps it from degenerating into "buffer more, always":

• Sender: "I ran out of credit and still have data" (ChannelWindowGrowthRequest). Only the sender can observe this. A receiver that drains promptly never sees its own buffer fill, even while the sender sits blocked across the round trip — which is precisely the case this fixes. (An earlier attempt at receiver-side saturation detection never fired, for exactly this reason.)
• Receiver: "…and it isn't because I'm behind" — granted only while its own reader is starved inside ReadAsync (ChannelWindowAdjust). If the reader is merely behind, a bigger window would buffer more unread data without moving any more of it.

A request arriving while the receiver is busy is deferred and answered when its reader next starves. Every request is answered, including a refusal that repeats the current size, so the sender is never left waiting on a reply that won't come. Consecutive refusals back the sender off exponentially, so a channel already at its cap doesn't spend a frame pair on every subsequent stall.

Growth is ×4, bounded per channel by Options.MaxChannelReceivingWindowSize and per connection by Options.MaxTotalChannelReceivingWindowSize; budget is returned when a channel closes.

Worth noting explicitly: a window is a limit on buffering, not an allocation. localWindowSize is used only as a Pipe pauseWriterThreshold and to size ACKs, so a channel that never fills one costs nothing.

No new protocol version

The two control codes are purely additive:

• Both the .NET and JS frame dispatchers end in a default: case that ignores unrecognized codes (MultiplexingStream.cs, MultiplexingStream.ts), and (ControlCode)reader.ReadInt32() is a plain cast that never throws.
• Frames are self-delimiting, so an unknown frame can't desync the stream.
• The exchange is self-negotiating: a receiver only ever grants in reply to a request, and only a peer that implements this sends one. Against an older peer, a channel spends one small ignored frame and then behaves exactly as a fixed window would.

Rather than assert this, MultiplexingStreamWindowFrameCompatTests relays a real connection through a filter that drops both frame types, and asserts that frames really were dropped so the test can't pass vacuously.

Measurements

LatencyBulkTransferBenchmark, 4 MB transfer, ms (lower is better):

one-way latency	window	v1	before	after
0 ms	default	6.7	13.3	13.5
1 ms	default	11.4	17.5	13.5
8 ms	default	33.2	94.6	47.7
8 ms	4 MB	32.1	31.7	31.6

Reproduced across separate runs with errors near ±1 ms. The residual gap to v1 at 8 ms is about one round trip: the first stall is how a channel learns it needs a bigger window, so some ramp is unavoidable.

The loopback benchmarks are inconclusive on my machine and I'm deliberately not claiming them as evidence. The same binary run twice gave 54.95 ms and 34.58 ms for the same case. Instrumenting a 32 MB loopback transfer showed zero growth requests — a prompt reader at zero latency never lets the sender stall — so the feature is simply inert there, neither helping nor hurting. Worth re-running the matrix on quieter hardware.

Known follow-ups

• A grant can land just as a transfer ends (the reader starves then too), committing budget to a channel that no longer needs it. Bounded and released on close, but imprecise.
• Because credit rides on examined rather than consumed bytes, an examine-heavy reader can buffer past the window. Pre-existing, but the growable pipe's higher pause threshold removes a backstop that previously caught it (at the cost of stalling the shared read loop).
• The JS implementation doesn't request or grant growth; it interoperates unchanged.