docs: document Windows proxy setup via NODE_OPTIONS=--use-env-proxy

[savvadesogle]

Summary

Adds a README section explaining how to route cloud-provider traffic through an HTTP/HTTPS proxy on Windows, in both cmd and PowerShell.

Motivation

Node's built-in fetch — used by every cloud LLM/search provider — ignores HTTP_PROXY / HTTPS_PROXY unless the process is started with the --use-env-proxy flag. In practice this means a user who sets:

set HTTP_PROXY=http://user:pass@proxy.example.com:8080

and then runs atomic-agent run sees LLM requests fail with fetch failed, because the proxy variables are silently ignored by the fetch transport. The README previously had no guidance about this.

Additionally:

• Only HTTP/HTTPS proxies are supported. A socks5:// URL is not understood by Node's fetch (undici only speaks HTTP CONNECT), so a socks5:// proxy value also fails with fetch failed.
• NO_PROXY is required so a local llama-server on 127.0.0.1 is not routed through the proxy.

Changes

• README.md — new <details> block "Windows: proxy for cloud providers" under "Requirements & Configuration", containing:
  • a cmd example (set NODE_OPTIONS=--use-env-proxy + HTTP_PROXY / HTTPS_PROXY / NO_PROXY),
  • a PowerShell example ($env:NODE_OPTIONS = "--use-env-proxy" + $env:HTTP_PROXY / $env:HTTPS_PROXY / $env:NO_PROXY),
  • notes that only HTTP/HTTPS proxies are supported (not socks5://),
  • the requirement to set the variables in the same shell that launches the agent (they do not persist between sessions),
  • a note that web-search tools shell out to curl, which reads the same proxy variables on its own.

Verification

• Docs-only change: no source or test files touched.
• npm run lint and npm test are unaffected (README only).