fix(mcp): forward configured headers to OAuth discovery on the server host

[Sayt-0]

Fixes #3148

Problem

A remote MCP server's headers were applied only to the main MCP channel, never to the OAuth flow. Grafana Cloud needs X-Grafana-URL on the OAuth discovery request to scope the flow to the right instance; without it the auth screen keeps prompting for the instance.

Root cause

Request	Transport used	Headers sent?
Main MCP channel	oauthTransport.base (header transport)	yes
OAuth discovery / token	oauthHTTPClient (bare singleton)	no

The protected-resource-metadata request (the one Grafana uses to scope the instance) went out with none of the configured headers.

Fix

• The OAuth HTTP client now forwards the configured headers...
• ...but only to the MCP server's own host. Requests to a third-party authorization server (URL taken from untrusted server metadata) get no headers, so Authorization / API keys can't leak.
• Preserved: SSRF protection, allow_private_ips, timeout, and ${headers.NAME} placeholders. The shared client singleton is never mutated.

Tests

Test	Verifies
...ScopesHeadersToMCPHost	header reaches the MCP host, not a third party
...NoHeadersReusesBaseClient	no headers configured -> base client returned unchanged
TestInitialize_CustomHeadersReachOAuthDiscovery	real Initialize() path; reverting the fix makes it fail (reproduces #3148)

Validation: go build ./..., golangci-lint run ./pkg/tools/mcp/... (0 issues), go test -race ./pkg/tools/mcp/ all pass.

Caveat

Scoping is on the exact host of the configured URL. If a server ever required the header on a host different from its MCP endpoint, the scope would need widening. Started strict, for safety.

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

One low-probability finding in newly added code: the host-scoping check may silently drop configured headers when the MCP server URL includes an explicit standard port (e.g., :443). The fix logic and security model (no credential leakage to third-party auth servers) are sound. All other security properties — SSRF protection, timeout, singleton non-mutation — are preserved correctly.

[docker-agent]

Assessment: 🟢 APPROVE

The host-scoping mechanism (hostScopedHeaderTransport) correctly forwards configured MCP server headers only to the MCP server's own host, preventing credential leakage to third-party authorization servers. The core security property is sound and well-tested.

Minor observations (no action required):

1. oauthHTTPClientWithHeaders omits Jar from base client (oauth_helpers.go:82) — The newly constructed *http.Client does not copy base.Jar. Today all base clients have a nil Jar, so this is harmless. If a cookie jar is ever attached to the base OAuth client in the future, it would silently disappear in the wrapped client.

2. req.URL.Host may be empty on redirect requests (oauth_helpers.go:101) — Go's HTTP client may reissue requests with Request.URL.Host == "" (host in Request.Host) on redirects. In that case hostWithoutDefaultPort returns "", the host check fails, and headers are silently dropped even if the redirect target is the MCP server itself. This only triggers on same-host redirects and is not the primary OAuth discovery path.

Both are low-risk edge cases that don't affect the primary use case described in this PR.