HTTP client ignores HTTPS_PROXY / HTTP_PROXY / NO_PROXY

fx's HTTP client doesn't appear to read the standard proxy environment variables (HTTPS_PROXY, HTTP_PROXY, ALL_PROXY, NO_PROXY, or the lowercase forms), so requests to providers go direct even when a proxy is set. That makes fx unusable on networks or in sandboxes where all egress has to go through a proxy.

Repro

fx 0.0.14 (fx-linux-x86_64), Debian bookworm and Ubuntu 24.04.

# Nothing listens on port 9, so any proxy-aware client fails to connect.
export HTTPS_PROXY=http://127.0.0.1:9 HTTP_PROXY=http://127.0.0.1:9
export OPENAI_API_KEY=sk-...   # a working key

mkdir -p ~/.fx && cat > ~/.fx/settings.json <<'JSON'
{"providers":{"openai":{"protocol":"openai-chat-completions",
  "base_url":"https://api.openai.com/v1",
  "auth":{"type":"bearer","env":"OPENAI_API_KEY"}}}}
JSON

FX_PROVIDER=openai fx ask --json --no-save --model gpt-4.1-mini "say hi"

Expected

The request goes to the proxy at 127.0.0.1:9 and fails to connect, as it would with curl, Node (NODE_USE_ENV_PROXY=1), Python or Go.

Actual

The request succeeds: fx connects to api.openai.com directly. AI Gateway (ai-gateway.vercel.sh) behaves the same way. The binary contains none of the strings HTTPS_PROXY, https_proxy, HTTP_PROXY, ALL_PROXY or NO_PROXY.

Suggested fix

Honour HTTPS_PROXY / HTTP_PROXY / ALL_PROXY (and lowercase) plus NO_PROXY for every outbound request (providers, gateway, MCP over HTTP/SSE, web fetch, update checks), using CONNECT for https:// targets. Zig's std.http.Client has proxy support (initDefaultProxies reads the environment), so this may mostly be wiring. Trusting SSL_CERT_FILE / SSL_CERT_DIR would also let a TLS-inspecting proxy's CA be added.

Possibly related: #1034.