fix: honor disabled proxy support for proxy settings

[EhabY]

Summary

• Stop deriving SSH proxy env vars from VS Code proxy settings when http.proxySupport is off.
• Apply the same http.proxySupport: off behavior to Coder API HTTP, WebSocket, and SSE paths by ignoring VS Code-derived proxy settings and proxy authorization.
• Preserve inherited proxy environment variables instead of scrubbing them.
• Watch http.proxySupport so disconnected WebSocket streams reconnect with updated proxy behavior, and SSH sessions prompt for reload when it changes.

Fixes #1017

Tests

• pnpm test:extension ./test/unit/api/utils.test.ts ./test/unit/api/coderApi.test.ts ./test/unit/remote/environment.test.ts
• pnpm test:extension
• pnpm format:check CHANGELOG.md src/remote/environment.ts test/unit/remote/environment.test.ts src/api/utils.ts src/api/coderApi.ts test/unit/api/utils.test.ts test/unit/api/coderApi.test.ts
• pnpm typecheck
• pnpm lint

Investigation notes

Issue #1017 is a regression from the v1.15.1 fix for #1010. The extension started translating VS Code proxy settings into HTTP_PROXY/HTTPS_PROXY/NO_PROXY for the coder ssh ProxyCommand, but only read http.proxy, http.noProxy, and coder.proxyBypass.

VS Code's http.proxySupport setting includes off, which means extension proxy support is disabled. With this patch, http.proxySupport: "off" disables only VS Code-derived proxy env/config injection. Existing process env proxy variables remain untouched, matching the selected remediation path.

For Coder API traffic, HTTP requests use createHttpAgent via Axios interceptors; WebSockets pass the same agent to ws; SSE fallback uses the same Axios instance through the streaming fetch adapter. Therefore the shared createHttpAgent behavior covers HTTP, WebSocket, and SSE connections.

workbench.browser.enableRemoteProxy was checked but is specific to VS Code browser/tunnel proxy behavior, not the SSH ProxyCommand or Coder API client.

Generated by Coder Agents.