fix(p2p): process one request per reqresp stream to enforce rate limit

[spalladino]

Context

The reqresp rate limiter is consulted once per inbound stream (streamHandler), but the sub-protocol handler was invoked once per chunk read from that stream (processStream). Req/resp is one-request-one-response and an honest sender writes a single payload before half-closing, but a malicious peer can open one stream (costing a single rate-limit token) and then push many request frames on it — each frame arrives as its own chunk and drives a full handler invocation (mempool / block / tree lookups). Per-peer and global rate limits are bypassed by the fan-out factor.

Approach

Make processStream handle exactly one request per stream: after emitting the response for the first chunk, the pipeline generator returns instead of looping over the rest of the source. Extra frames a peer queued on the same stream are discarded when the stream closes, so work is bounded to one request per token. This does not regress legitimate traffic — no code path pipelines multiple requests on a single stream, and the one-chunk-per-request framing is already in force.

The alternative (per-invocation rate checks inside the loop) was rejected: nothing pipelines, and mid-stream status signalling is broken on the requester side, which parses the first chunk as status and concatenates the rest as data.

Adds a unit test that drives processStream with three frames on one stream and asserts the handler runs once and the sink receives a single SUCCESS + response pair.

Fixes A-1324