Bound HTTP/1 request metadata queue under pipelining

Follow-up from the post-merge review of #23.

## Problem

The HTTP/1 rewriting path creates a `tokio::sync::mpsc::unbounded_channel` for request/response correspondence. `rewrite_request_stream` queues one `RequestMeta` before every forwarded request.

If an upstream continues reading requests but delays its responses, an unauthenticated client can pipeline requests indefinitely. The request pump continues adding metadata while the response pump cannot drain it, allowing per-connection memory growth without a defined bound.

This affects routes using HTTP header rewriting for X-Forwarded-For or JA3/JA4 forwarding.

## Location

- `src/http_proxy.rs`: `proxy_http1_rewriting`, `rewrite_request_stream`
- Introduced by #23 while fixing Upgrade/CONNECT response correspondence.

## Acceptance criteria

- Replace the unbounded metadata channel with bounded backpressure or enforce a documented maximum number of outstanding pipelined requests.
- The request pump must stop advancing when the response side reaches that limit.
- Preserve correct correspondence for ordinary requests, HEAD, interim 1xx responses, Upgrade, and CONNECT.
- Add a test with an upstream that reads requests but withholds responses, proving queued metadata remains bounded.
- Include the exact 64 KiB request-header boundary in the test cleanup: `MAX_HEADER_SIZE + 1` must be rejected rather than relying on the current 70 KiB case.

Start in src/http_proxy.rs at proxy_http1_rewriting and rewrite_request_stream, then trace how request metadata corresponds to ordinary requests, HEAD, interim 1xx responses, Upgrade, and CONNECT. Run the existing HTTP/1 rewriting tests before adding a withheld-response upstream test that proves metadata stays bounded, and include the MAX_HEADER_SIZE + 1 rejection case for the exact 64 KiB boundary.

Written by the indexing model from the issue text.