Parity tests: Handle request-body mutation

The parity suite doesn't exercise plugin-driven body mutation. A plugin that rewrites the request body via pctx.SetBody (declaring WritesRequestBody: true) has its output travel to the upstream through completely different code paths on each listener — Envoy's BodyMutation proto message for extproc, direct Request.Body replacement for the proxies.

Why it matters

• A rewrite that lands on the wire on one listener and gets dropped on the other is silent — the pipeline plugin sees success, upstream sees the original bytes, only one deployment shape misbehaves.
• Header rewrites (Content-Length, Content-Type) accompanying a body change follow a separate encoding path per listener and can drift independently from the body itself.
• The tool-prune plugin depends on this exact contract in production; without a parity fixture, its behavior across deployment shapes is asserted only by end-to-end tests.

Fix

Add a mutateRequestBody []byte knob to spyConfig. When set, spyPlugin.OnRequest calls pctx.SetBody(cfg.mutateRequestBody) and the fixture:

• Declares WritesRequestBody: true in Capabilities.
• Asserts the upstream (httptest.Server on the proxy path, mock stream response on extproc) receives the mutated bytes verbatim on both listeners.
• Asserts the mutated Content-Length reaches upstream headers consistently.

Depends on the ReadsBody fixture landing first (#937) since request-body mutation shares the two-phase handshake plumbing.

Follow-up from #935.

Start with the parity suite's spyConfig and spyPlugin.OnRequest entry points, then inspect the existing ReadsBody fixture and dependency on #937. Add coverage for SetBody with WritesRequestBody enabled, verifying that both listener paths deliver the mutated bytes and matching Content-Length to their upstreams.