fix(fetch): support corporate proxies with TLS interception

[sleicht]

Summary

The fetch tool's HTTP client was created via bare Client::new(), which caused two failures in corporate proxy environments:

1. Hickory-DNS bypasses proxy: The workspace-wide hickory-dns cargo feature made the client perform direct DNS resolution, bypassing HTTP_PROXY/HTTPS_PROXY environment variables entirely.

2. Corporate CA not trusted: The rustls-tls backend only trusts the webpki-roots CA bundle, so proxies that perform TLS interception (MITM) have their re-signed certificates rejected.

Fix

• Call .hickory_dns(false) on the client builder to delegate DNS to the system resolver / configured proxy.
• Load additional root CA certificates from well-known environment variables so corporate proxy CAs are trusted:
  1. FORGE_ROOT_CERT_PATHS — comma-separated list of PEM/DER paths (Forge-specific)
  2. SSL_CERT_FILE — single PEM bundle (common convention)
  3. NODE_EXTRA_CA_CERTS — single PEM file (Node.js convention)
  4. REQUESTS_CA_BUNDLE — single PEM bundle (Python convention)

Testing

Verified working in a corporate environment with:

• HTTP proxy (HTTP_PROXY/HTTPS_PROXY set to http://proxy:8080)
• TLS-intercepting proxy (Swisscom Proxy Sub CA re-signing certificates)
• NODE_EXTRA_CA_CERTS pointing to the corporate CA PEM file

Before this fix, every fetch call failed with error sending request for url. After the fix, fetches work correctly through the proxy.

Related

• Fixes [Bug]: Fetch tool ignores HTTP_PROXY/HTTPS_PROXY — uses bare reqwest::Client bypassing proxy configuration #3329
• PR fix: disable hickory-dns in auth HTTP client #2828 — same hickory-dns fix for the auth client
• PR fix(auth): route HTTPS traffic through HTTP_PROXY when no HTTPS proxy is set #2744 (closed) — earlier proxy routing attempt

[CLAassistant]

All committers have signed the CLA.