Do not follow redirects when sending a decoupled response

The scheme allow-list and the address checks both run against the endpoint
reference the caller supplied, and nothing re-examines where a redirect leads.
HttpClientBuilder is used with defaults here, and RequestConfig.DEFAULT has
redirects enabled with a limit of 50, so a caller whose own reply endpoint
answers 307 could name somewhere the policy had already refused -- the
HTTP-only instance-metadata address being the obvious one. That is precisely
the protocol-downgrade route past an HTTPS-only allow-list.

Redirects are now disabled for a server-side send to a non-anonymous
destination, which is exactly the decoupled-response case. The reply is
fire-and-forget, so nothing legitimate depends on following one. Ordinary
client-side requests are untouched.

The test drives the real RequestImpl against a local server that answers 307,
and asserts the rebound target is never reached. It carries a control that
sends the same request client-side and asserts the target IS reached, so the
main assertion cannot pass by the request simply failing, plus an anonymous
server-side case to show the restriction is scoped and not blanket.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>