Parity tests: Cap divergence for request and response bodies

The inbound-request-overflow fixture (#937) covers extproc + reverseproxy at their shared 1 MiB cap. Two adjacent caps have no coverage today, and each is a real divergence between deployment shapes:

Why it matters

A body between 1 MiB and 10 MiB (agent egress with concatenated history + tool manifest, LLM streaming response) is accepted on the laptop path (forwardproxy) and rejected on the Kubernetes envoy-sidecar path (extproc). The two caps have grown independently in authbridge/authlib/listener/{extproc,forwardproxy}/server.go — nothing forces the operator-visible contract to be either "same cap" or "documented gap."

Anthropic Claude Code sessions produce 5 MiB request bodies (measured in PR #904); response bodies follow suit.

Fix

Two fixtures, one shape:

1. Outbound request-body overflow — body between 1 MiB and 10 MiB, direction: pipeline.Outbound. Forwardproxy accepts (pipeline runs, wire status 200); extproc rejects (pipeline refused pre-run, wire status 413).
2. Response-body overflow — upstream serves a body between 1 MiB and 10 MiB. Same asymmetric outcome: forwardproxy accepts, extproc + reverseproxy reject with 502.

Both are asymmetric-per-listener — not a naive assertParity call. Options:

• Add an expectPerListener map[string]expectedBehavior field to the fixture, or
• Use per-listener sub-tests rather than the shared harness.

Follow-up from #937.

Start with the inbound-request-overflow fixture referenced from #937 and inspect authbridge/authlib/listener/{extproc,forwardproxy}/server.go to understand the existing caps. Add request- and response-body overflow coverage with per-listener expectations for forwardproxy, extproc, and reverseproxy. Done means bodies between 1 MiB and 10 MiB produce the specified acceptance or rejection status for each listener.