fix: propagate Content-Length header to upstream requests

[octo-patch]

Fixes #2366

Problem

When the request body is passed through unchanged (OpenAI-compatible pass-through mode, e.g., for Azure channels with no format conversion needed), Go's http.NewRequest receives a generic io.Reader and cannot determine the content length. It sets ContentLength to -1, which causes the Go HTTP client to send the request with Transfer-Encoding: chunked instead of a Content-Length header.

Some upstream APIs — specifically Azure's grok model — require an explicit Content-Length header and reject chunked requests with:

{"error":{"message":"Content-Length header is required to make request."}}

Solution

In DoRequestHelper, after creating the upstream *http.Request, check if ContentLength is still -1 (unknown). If so, inherit it from the original client request (c.Request.ContentLength).

This fallback applies only to the pass-through case. When the request body has been re-serialized via ConvertRequest (into a *bytes.Buffer), Go's http.NewRequest already computes the length automatically and ContentLength will be non-negative — the fallback is not applied.

This mirrors the existing pattern in relay/controller/audio.go where req.ContentLength = c.Request.ContentLength is set for Azure audio requests.

Testing

• Verified the fix targets the same code path that the audio controller already handles correctly.
• The change is minimal and does not affect re-serialized requests (where ContentLength is already set by Go).