fix: pace block sync receives during response bursts

[czarcas7ic]

Motivation

Ordinary block sync can exhaust the receive message budget during a burst of block bodies and completion messages. The transport then closes a healthy connection, discarding useful in-flight work and forcing recovery. This still occurred on two clients in the eight-client validation after correcting fractional refill accounting.

Solution

Block-sync readers wait for shared message credit while retaining their current bounded frame. Rate and size limits remain enforced, FIFO admission preserves waiter order, and cancellation releases the waiter without consuming future credit. Other ordered streams retain their existing rejection behavior.

Testing

All 74 handler tests and all-target network Clippy passed on macOS, including a real QUIC worker test of outbound progress while receive admission waits. The final combined serving/pacing test revision passed all 1,191 Linux network tests (4 ignored) and all-target Clippy. The production-equivalent revision also passed its release build. Three existing tests in the expanded Mac suite require an unavailable loopback alias.

The eight-client native run reached every target without rate rejections or peer parks. In a separate genesis-sync pair, the baseline hit a rate rejection and disconnected; the candidate successfully paced 117 frames, averaging about 1 ms per wait, without a during-sync closure. Completion time was essentially unchanged at 236 seconds. Startup retries remain preserved, and broader qualification and production defaults are still pending.

Used Codex for implementation, tests and validation.