fix(providers): pin Azure OpenAI/Anthropic endpoints to validated IP

[waleedlatif1]

Summary

• Fix TOCTOU DNS-rebinding SSRF in the Azure OpenAI and Azure Anthropic providers: both validated request.azureEndpoint with validateUrlWithDNS but then discarded the resolved IP and handed the raw hostname to the SDK/fetch, which re-resolved DNS at connect time — letting a short-TTL rebinding host pass validation (public IP) then connect to an internal IP (e.g. 169.254.169.254).
• Add createPinnedFetch(resolvedIP) in input-validation.server.ts: a standard fetch routed through an undici Agent with a pinned DNS lookup, so the connection goes to the validated IP while the hostname is preserved for TLS SNI / Host header. Because the lookup always returns the validated IP, redirect hops can't rebind to an internal address either. Dispatchers are pooled by IP (LRU, max 64) for keep-alive reuse — same pattern as lib/mcp/pinned-fetch.ts.
• Wire the pinned fetch into both providers, but only on the user-supplied-endpoint path: Azure Anthropic's new Anthropic({ fetch }), Azure OpenAI's chat-completions new AzureOpenAI({ fetch }), and both Responses-API configs via a new optional ResponsesProviderConfig.fetch (defaults to global fetch).
• Trusted server-env endpoints and all non-Azure providers are unchanged.

Type of Change

• Bug fix (security)

Testing

• New createPinnedFetch unit suite (8 tests): pinned lookup returns the validated IP for any hostname (IPv4/IPv6), dispatcher forwarding + init preservation, pooling/eviction.
• New Azure OpenAI + Azure Anthropic wiring suites (8 tests): user endpoint pins; trusted-env endpoint does not; blocked validation throws before any client/fetch.
• typecheck clean, check:api-validation passes, full security + provider suites green (453 tests).

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)