Send the account login through the system proxy

[Pixnop]

What the player sees

A network that requires a proxy no longer breaks login by itself. The login request now goes through the same proxy every other launcher request already used, and a proxy this launcher cannot route through (an authenticated proxy, or a SOCKS proxy) fails with a message that names a proxy as the cause, the same sentence a plain connection failure already shows, instead of a generic "check your connection or firewall".

Why

Login posts through requestBoundedTextViaNode, a raw Node https transport kept only because the auth service rejects Electron's net.request fetch metadata (#76). That transport set no agent and read no proxy, while net.request (every other call) inherits the system proxy from Electron on its own. On a network that requires a proxy, everything else in the launcher worked and only login failed.

Decisions

• The proxy is resolved from Electron's own session (session.defaultSession.resolveProxy), the same source net.request reads, so it follows the OS settings and Chromium switches the same way the rest of the launcher does. Parsing that PAC-style answer is a pure function, parseProxyResolution (src/domain/net/proxy.ts).
• An HTTP proxy answer is tunneled with a plain CONNECT (node:http's own request, then node:tls upgrading the returned socket for an https: target): no new dependency.
• DIRECT keeps the prior path byte for byte. HTTPS_PROXY/HTTP_PROXY are read as a fallback only when the session itself answers DIRECT, with NO_PROXY respected for the login host.
• Known limits, stated rather than silently mishandled: Chromium's proxy resolution carries no credentials, so a proxy that answers a CONNECT with 407 fails the login with a fixed reason instead of a prompt this launcher does not have; a SOCKS proxy has no client here and fails the same way, whether Chromium's own session resolved it or HTTPS_PROXY/HTTP_PROXY named one directly. An https: proxy URL from the environment fallback tunnels over its own TLS connection before the CONNECT (since review round 1); Chromium's own HTTPS-scheme PAC answer still comes back unsupported, since a PAC answer never carries more than a host and a port to act on. Every one of these joins the existing network-unreachable family, whose sentence already tells a player to check a proxy.
• Every log line stays a fixed token (proxy-used, proxy-direct, proxy-unsupported, proxy-auth-required), never the resolved host.

Testing

• Domain: parseProxyResolution against every PAC shape (PROXY, SOCKS4/SOCKS5, HTTPS, DIRECT, a fallback list, garbage, empty).
• IPC: a local CONNECT-accepting proxy stub relays the login through the tunnel and gets the real response back with the same headers and body; a proxy answering 407 maps to proxy-auth-required before the origin is ever reached; a SOCKS answer maps to proxy-unsupported before any socket opens; DIRECT bypasses the tunnel; HTTPS_PROXY is used only as a DIRECT fallback, and NO_PROXY still bypasses it.
• Renderer: the network-unreachable family sentence, the one both new reason tokens join, is confirmed to name a proxy; no new locale string was needed, en-US and fr-FR already carried the wording.
• Mutation-check on three rules (the PROXY/SOCKS parse split, the 407 mapping, the NO_PROXY bypass): reverted each, confirmed red, restored, confirmed green and clean with git status --short.

Review round 1

Addressed in the order raised:

1. Environment proxy discarded its own scheme (src/ipc/network.ts:350, parseProxyUrl now in src/domain/net/proxy.ts:58). HTTPS_PROXY/HTTP_PROXY no longer get flattened to a bare PROXY host:port: the URL's scheme is kept, so http: and https: both tunnel over CONNECT (connectThroughProxy, src/ipc/network.ts:403, now sends the CONNECT itself over node:https's request rather than node:http's when the proxy is secure), and a socks:/socks4:/socks5: URL comes back the same recognised-but-unimplemented shape a SOCKS PAC answer already gets instead of being dialed as if it were HTTP. Test: tests/ipc/networkProxy.test.ts:287, a self-signed-certificate proxy proving the CONNECT itself goes out over TLS, and a socks5:// value refused up front rather than reaching for a socket.
2. NO_PROXY ignored a port on the entry (matchesNoProxy, moved out of src/ipc/network.ts into src/domain/net/proxy.ts:95 since it never touched Electron or a socket). An entry can now carry an optional :port, bypassing only when both the host and the target's own effective port agree; a port-less entry still bypasses every port for that host, unchanged. Test: tests/domain/net/proxy.test.ts:48, covering a bare host, a ported host (matching and mismatched), a leading-dot suffix, *, spaces around an entry, and a case difference.
3. No HTTPS-target coverage through the tunnel (tests/ipc/networkProxy.test.ts:320). A new self-signed-certificate origin, tunnelled through a plain HTTP proxy, proves the login body actually crosses the TLS wrap connectThroughProxy puts around the tunnelled socket, not just that some response comes back. Confirmed against a real regression: temporarily skipping that wrap failed this test.

Gate: typecheck clean, lint:ci 0 errors (14 pre-existing warnings), format:check clean, test:coverage 4453 passed / 2 skipped, thresholds cleared (statements 94.29%, branches 90.47%, functions 95.01%, lines 95.98%).

Closes #481.

[Zaldaryon]

Changes requested. The direct and Electron proxy paths are covered by focused tests, but the environment fallback still changes proxy semantics. The required checks are green. I added comments for the scheme and NO_PROXY handling, and the tests should cover an HTTPS target through CONNECT before this is ready.

[Pixnop]

Pushed three commits, one per point.

1. The environment fallback keeps HTTPS_PROXY/HTTP_PROXY's own scheme (parseProxyUrl). An https proxy tunnels over its own TLS before the CONNECT; a socks URL is refused up front instead of being dialed as HTTP.

2. NO_PROXY now parses an optional :port per entry, bypassing only when the target's effective port agrees too; a port-less entry still bypasses every port, unchanged. Moved to the domain layer as matchesNoProxy since it never touched Electron.

3. Added an https-target-through-CONNECT test with a self-signed certificate, proving the login body crosses the TLS-wrapped tunnel.

PR body has a Review round 1 section with file:line and gate figures. Ready for another look.

[Zaldaryon]

Reviewed the current head. The proxy implementation now preserves supported proxy schemes, handles port qualified NO_PROXY entries, and covers HTTP CONNECT plus TLS on both sides of the tunnel. The required checks pass in the Ubuntu and Windows environments, including typecheck, lint, the full test matrix, build, and the gate test. Approving.