Feature request: configure HTTP(S) proxy in ~/.jcode/config.toml

Problem

jcode can work behind a proxy when proxy environment variables are configured outside jcode, but there is no supported proxy setting in ~/.jcode/config.toml.

Current behavior

The HTTP client stack relies on reqwest's system-proxy support, which reads HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY.

OpenAI's WebSocket transport is a separate path and does not use reqwest's proxy configuration, so proxy setups can work for HTTP requests but fail for streaming.

Proposed configuration

[network]
proxy = "http://127.0.0.1:7890"
no_proxy = "localhost,127.0.0.1,.internal"

When proxy is unset, preserve the current environment-variable behavior. A configured value should explicitly apply to HTTP and HTTPS requests. Invalid values should produce a clear, redacted error.

Scope

• Apply the setting to shared async and blocking reqwest clients, provider/auth/tool traffic, updates, telemetry, and embeddings.
• Keep NO_PROXY behavior, or provide an equivalent TOML setting.
• Decide whether WebSocket transport should use an HTTP(S) fallback when a proxy is configured, or support HTTP CONNECT explicitly.
• Avoid copying TOML values into process-wide proxy environment variables.
• Document whether changing the setting requires a restart.

Issue #974 appears related because it covers SOCKS proxy support for provider traffic. This request is specifically about a first-class TOML setting and consistent HTTP(S) proxy behavior across jcode's network clients.

Start with the configuration handling for ~/.jcode/config.toml, then trace the shared async and blocking reqwest clients and the separate OpenAI WebSocket transport. Check how provider, auth, tool, update, telemetry, and embedding traffic is routed; done means the proxy behavior, NO_PROXY handling, invalid-value errors, WebSocket decision, and restart requirement are defined and documented.