fix: route WebSocket connections through the configured proxy

[Daniel Elsner (delsner)]

Problem

When running behind a corporate proxy, ClientWebSocket connections (used for live console feed streaming in both JobServer and ResultsServer) were not going through the proxy configured via http_proxy/https_proxy environment variables. This caused:

• A 502 response from the proxy when attempting the WebSocket upgrade (the proxy intercepted the connection but didn't support forwarding the upgrade)
• Subsequent NullReferenceException retries in ResultsServer after the failed attempt set _websocketClient to null

Meanwhile, regular HTTP traffic (action downloads, API calls) correctly went through the proxy via HttpClientHandlerFactory, so curl against the same endpoints worked fine.

Root cause

Two issues in combination:

1. ClientWebSocket.Options.Proxy was never set in JobServer.InitializeWebsocketClient or ResultsServer.InitializeWebsocketClient. The client fell back to .NET's HttpClient.DefaultProxy, which does not recognise wss:///ws:// URI schemes and silently bypasses the proxy for WebSocket connections.

2. RunnerWebProxy.IsBypassed and GetProxy only handled http/https schemes. For a wss:// URI, IsBypassed would skip the "no proxy configured" short-circuit, and GetProxy would return the HTTP proxy address instead of the HTTPS proxy — both wrong.

Fix

• Set Options.Proxy = HostContext.WebProxy on every newly created ClientWebSocket in JobServer and ResultsServer.
• Fix RunnerWebProxy.IsBypassed to map wss → https and ws → http before the scheme-based bypass checks.
• Fix RunnerWebProxy.GetProxy to return _httpsProxyAddress for wss:// URIs.

Test plan

• Run the runner behind a corporate proxy with https_proxy set and verify WebSocket live-console streaming works
• Verify runner without proxy configured is unaffected (IsBypassed still returns true when no proxy address is set)
• Verify no_proxy bypass rules still apply correctly to wss:// URLs