Windows corporate proxy: HTTPS_PROXY/HTTP_PROXY env vars not respected for extension HTTP calls #1941

Environment

• OS: Windows 11 Enterprise (corp-managed)
• VS Code: latest
• Extension: databricks.databricks (latest)
• Network: corporate HTTPS-intercepting proxy with custom CA cert

Description

On Windows corp machines with an HTTPS-intercepting proxy, the extension fails silently when environment variables HTTP_PROXY, HTTPS_PROXY, or NO_PROXY are set at the system or user level. Cluster connectivity and authentication requests bypass these variables and fail with UNABLE_TO_GET_ISSUER_CERT_LOCALLY or timeout errors.

VS Code itself respects http.proxy in settings and the system proxy, but the extension's internal Node.js fetch calls do not inherit the proxy configuration from the VS Code host process in all code paths.

Steps to Reproduce

1. Set HTTPS_PROXY=http://proxy.corp.example.com:8080 as a Windows system environment variable
2. Open VS Code on a corp machine where direct internet access is blocked
3. Configure Databricks workspace host and attempt to authenticate via OAuth
4. Observe: authentication fails with a network error; the extension does not route through the configured proxy

Expected vs Actual Behavior

Expected: Extension respects HTTPS_PROXY/HTTP_PROXY env vars (and VS Code's http.proxy setting) for all outbound HTTP requests.

Actual: Extension network calls bypass proxy, causing failures on networks where direct egress is blocked.

Additional Context

Related: #1846 covers cluster connectivity behind proxy. This issue is broader — covering auth flows, bundle deployment calls, and any other extension HTTP traffic. Documenting which env vars are supported and adding a proxy configuration section to the extension README would also help corp users.