[Bug]: Main-process network calls (Cloud auth + Relay control) don't honor the app's configured HTTP proxy

### Operating system

Windows

### Orca version

v1.4.199

### Details

### Summary
On a corporate network that requires all outbound HTTPS/WSS to go through an HTTP proxy (direct connections are blocked/dropped), two related features fail even though the app's own **Settings → Network → HTTP Proxy** is correctly configured with the working proxy and an appropriate bypass list:

1. **"Pair this PC" / Cloud sign-in**: after successfully signing in via the browser (which does honor the OS/browser proxy) and being redirected to `http://127.0.0.1:/auth/callback?code=...`, the desktop app shows a toast **"Failed to connect profile — fetch failed"**.
2. **Mobile pairing via Orca Relay (QR code)**: fails with `Couldn't create a Relay pairing code`, backed by:
```json
{
"kind": "mobile_pairing_relay_failure",
"preferredConnectionMode": "automatic",
"failure": {
"code": "relay_control_not_active",
"stage": "create_pairing_relay",
"message": "Relay pairing invite request failed"
}
}
```

### Root cause (confirmed by extracting `app.asar` and reproducing outside the app)

- The Cloud auth code exchange (`connectCurrentOrcaProfile` → IPC `orcaProfiles:connectCurrent` → main-process `Ici()` → `rsi()` → `_0()`) calls `POST https://login.onorca.dev/v1/desktop/auth/session` using **Node's built-in `fetch` (undici)** directly in the Electron **main process**.
- This `fetch()` call does **not** use the OS proxy, nor the proxy configured in Orca's own Settings (that setting only appears to apply to Chromium/renderer network stack). On a network where direct outbound HTTPS is blocked, the call hangs and fails with:
```
FETCH ERROR: fetch failed
CAUSE: ConnectTimeoutError: Connect Timeout Error (attempted address: login.onorca.dev:443, timeout: 10000ms)
code: 'UND_ERR_CONNECT_TIMEOUT'
```
- Reproduced outside Electron with plain Node (`node -e 'fetch("https://login.onorca.dev/v1/desktop/auth/session", ...)'`): fails the same way unless `HTTPS_PROXY`/`HTTP_PROXY` env vars are set **and** `NODE_USE_ENV_PROXY=1` is set (Node 24+ opt-in for undici to respect proxy env vars). With those set, the request correctly reaches the server (gets a real `400 invalid_request` response instead of timing out).
- The **Relay pairing** control channel (`relay_control_not_active` thrown from `originPool.activeControl` being null in the relay-host code path, connecting to `relayDirectorUrl` = `https://relay.onorca.dev` by default) appears to have the same class of problem — it also runs in the main process and does not appear to route through the configured HTTP proxy. Setting `NODE_USE_ENV_PROXY=1` (which only affects `fetch`/undici) did **not** fix this second failure, consistent with the Relay control channel using a different networking path (likely a raw WebSocket) that has no proxy support at all.

### Suggested fix
- Apply the app-configured HTTP proxy (`Settings → Network → HTTP Proxy` + bypass rules) to **all** main-process outbound network calls, not just the ones going through Chromium's `net` module — specifically:
- The Cloud auth endpoints (`login.onorca.dev`: `/v1/desktop/auth/*`)
- The Relay director/control WebSocket connection (`relay.onorca.dev`)
- Alternatively/additionally, respect standard `HTTP_PROXY`/`HTTPS_PROXY`/`NO_PROXY` environment variables for both the undici-based `fetch` calls and any WebSocket connections used for Relay pairing.

### Environment
- Orca version: 1.4.199 (Windows)
- OS: Windows 11 Pro 10.0.22631
- Network: corporate network behind a Fortinet SSL-inspecting proxy (`proxy2.fujinet.vn:8080`), direct (non-proxied) outbound HTTPS/WSS to the internet is blocked
- Workaround found: "Use LAN" pairing (local network/Tailscale) works fine, since it doesn't require the Relay control channel to the internet.

### Diagnostics
{
"kind": "mobile_pairing_relay_failure",
"preferredConnectionMode": "automatic",
"failure": {
"code": "relay_control_not_active",
"stage": "create_pairing_relay",
"message": "Relay pairing invite request failed"
},
"at": "2026-09-11T03:18:33.572Z"
}

Start by tracing connectCurrentOrcaProfile through the orcaProfiles:connectCurrent IPC path and the main-process Ici(), rsi(), and _0() calls, then inspect the relay-host path around originPool.activeControl and relayDirectorUrl. Verify how the configured HTTP proxy and bypass rules are represented, and reproduce both Cloud auth and Relay pairing failures on a proxied network; done means both outbound paths work through the configured proxy while preserving bypass behavior.

Written by the indexing model from the issue text.