fix(client): parse Windows per-scheme proxy settings

[sb123sb123]

Fixes hyperium/hyper#4067

Problem

On Windows, WinINET can store ProxyServer as semicolon-separated per-protocol entries such as http=host:8080;https=host:8443;socks=host:1080. Matcher::from_system() currently passes that whole value to both proxy slots, so the matcher cannot use the configured proxies.

Issue: hyperium/hyper#4067

Cause

The Windows system-proxy path treated ProxyServer as only the legacy single-proxy form. The shared proxy URI parser then interpreted entries such as socks=host:1080 as an invalid HTTP proxy value.

Fix

Parse Windows ProxyServer entries before building the matcher. Preserve the legacy single-proxy form, apply http= and https= entries to their respective slots, use a supported socks5:// URI as the fallback for socks=, and ignore unrelated entries. Explicit protocol entries take precedence over the SOCKS fallback, while environment values keep their existing precedence.

Tests

• cargo fmt --all -- --check
• cargo test --target x86_64-pc-windows-msvc --lib --no-default-features --features client-proxy,client-proxy-system -- --nocapture (17 passed)
• cargo check --target x86_64-pc-windows-msvc --all-targets --no-default-features --features client-proxy,client-proxy-system
• cargo clippy --target x86_64-pc-windows-msvc --all-targets --no-default-features --features client-proxy,client-proxy-system (passes with the two existing warnings noted below)

Limitations

The regression tests exercise the Windows parser directly and do not modify the host Windows registry. Strict Clippy with -D warnings remains blocked by two pre-existing unnecessary_map_or warnings at src/client/proxy/matcher.rs:514 and :518; those unrelated lines were not changed.

AI assistance disclosure

This PR was prepared with autonomous AI assistance for issue inspection, implementation, testing, and PR preparation. The changes and test results are disclosed here for maintainer review.