## Why
HTTPS requests and WebSocket connections on Windows need to authenticate when a proxy rejects `CONNECT` with status `407`.
## What changed
- Retry proxy challenges through the existing Windows authentication helper, using the signed-in user's Negotiate or NTLM credentials. Treat an origin `407` as a normal HTTP response.
- Bridge authenticated tunnels to the HTTP client through destination-specific named pipes, retaining redirect checks and TLS backend fallback without caching those tunnels across destinations.
- Carry explicit CA certificates and client identities into HTTPS proxy TLS configuration, and apply the configured connect timeout when opening authenticated HTTP tunnels.
GitOrigin-RevId: ec7d9168972a7a640350e5348cfca40307390fbf
## What changed
Expose `connect_windows_proxy` for callers handling a CONNECT `407` response. Use libcurl with the signed-in Windows user's Negotiate or NTLM credentials, then return the authenticated connection with buffered data preserved.
Support HTTP and HTTPS proxies, with default or caller-provided TLS configuration. HTTPS proxies requiring authentication tokens bound to their TLS connection are unsupported.
Enable libcurl's NTLM support in Cargo and Bazel builds.
## Testing
Add a Windows-only test asserting that libcurl provides NTLM, SPNEGO, and SSPI support.
GitOrigin-RevId: 4ed7d2208766404b6125ce2f4b5f91de5616a37f
efrazer-oai