feat(http3): streamed response bodies, pushed rather than pulled

[MDA2AV]

ioxide.http3 could only return a finished Http3Response, so a large body cost its own size in memory and an endless one could not be expressed at all. The request direction already streamed through Http3Request.BodyReader — this is the other half.

Why this one is simple

Owning the framing means a chunk is just [0x00][varint length][payload] handed to the QUIC stream. No data-reader callback to answer, nothing to defer out of a library call, no buffer whose lifetime something else dictates.

Compare the nghttp3 version (#172): nghttp3 pulls, which needs WOULDBLOCK, resume_stream, a deferred resume so a pull does not re-enter writev, and native buffers because it holds pointers into them across the callback. None of that exists here — QUIC streams are independent, so nothing has to be interleaved either.

Http3ResponseWriter	IBufferWriter<byte>, so a serializer or a framework response sink writes into it unchanged. Pooled along with its buffer.
RunStreamedResponseAsync	Dispatches through its own path, inside the pass that made the request ready — so a writer's sends flush with that pass exactly as a buffered Submit does.

Backpressure is the connection's send retention: FlushAsync waits while CanQueueSend is false, so a producer cannot outrun a peer that has stopped reading.

Numbers

8 × 1 KiB chunks, 2 reactors, 16 connections, 8 streams:

	req/s	MB/s
nghttp3 streamed	92,689	724
pure C# streamed	122,083	954

1.32×, and the simpler implementation.

Sample

Playground/Http3/ManagedStreamed shows both directions at once — uploads pulled a chunk at a time through BodyReader, downloads pushed through the writer, and an endless /feed that buffering cannot express at all.

Verification

Unit 29, E2E 46, Http 35, Tls 15, File 4, Chaos 37 pass. 990,134 requests with zero failures, plus an endless /feed whose client disappears mid-stream followed by 348,393 more requests served — the case that previously wedged the reactor in the nghttp3 path.