fix(hyperlane): stop dropping pipelined requests

[vshengbro]

Summary

HTTP pipelining was completely broken: a client that wrote several requests
in one call received a response for only the first, and every later request
was silently discarded. This restores it, which is also where the large
throughput gain comes from.

A single socket read can deliver bytes belonging to the next pipelined
request. fill_http_from_stream created a fresh PooledReader per request,
so those read-ahead bytes were dropped along with the buffer when the reader
was dropped and returned to the thread-local pool. The next request took a
recycled buffer with start/end reset to zero, and the data was gone.

Stream now carries the unconsumed bytes across requests.

Changes

• type/src/stream/struct.rs — Stream gains leftover plus its
  start/end offsets, holding bytes already read from the socket but not
  yet parsed into a request
• type/src/stream/impl.rs — fill_http_from_stream seeds the reader with
  the carried bytes before parsing and stores back whatever the reader read
  past the current request
• core/tests/server/fn.rs — regression test: writes 8 pipelined requests on
  one connection and asserts all 8 responses return
• core/tests/mod.rs — import AsyncReadExt for the test client

All self access is sequenced before the reader borrows the socket or after
the reader is dropped, so the mutable borrows of Stream and TcpStream
never overlap.

Verification

Measured on an 18-core Mac, release build, closed-loop keep-alive client,
before and after on the same machine in the same session:

Scenario	Before	After
depth 64	0 QPS (32/32 conns failed)	863,653 QPS
depth 16	0 QPS	836,190 QPS
depth 4	0 QPS	523,048 QPS
depth 1 (serial)	189,065 QPS	189,812 QPS

Serial QPS is flat by design: this fixes correctness, not the single-request
path. The pipelined figures are what the fix unlocks.

• The regression test fails against the unfixed parser with
  "expected 8 pipelined responses, got 1", and passes once restored
• cargo test --workspace — 725 passed, 0 failed
• cargo clippy --all-targets — 0 warnings
• crate fmt --check — clean
• audit_rust_standards.py . — 51/51 PASS

Notes

Two hypotheses were tested and rejected before landing this, so they are not
in the diff:

• Disabling the per-request read timeout (the default is 6000 ms, so every
  request goes through tokio::time::timeout) changed nothing: 190.7k
  versus 194k QPS
• Lowercasing header keys into a stack buffer was a no-op, because the value
  is still needed as an owned String for the header map

Profiling on this machine could not produce usable leaf attribution, so the
19 allocations per request that remain were left alone rather than optimized
blind.

🤖 Generated with Hermes