Add Windows split tunneling - #151

I reviewed the routing mechanism in this PR. It does not provide per-application split tunneling as #114 specifies:

• collect_destinations() observes remote IPs used by selected processes only after those connections already exist.
• apply_routes() then installs ordinary /32 host routes for those destination IPs through the physical gateway.
• A Windows route is selected by destination prefix/interface/gateway, not by originating process. Once installed, the route applies system-wide: every application connecting to the same IP bypasses the VPN, not just the selected app. The relevant command semantics are documented here: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/route_ws2008

This also means the selected app's first connection has already used the VPN before its destination can be discovered, while long-lived existing connections are not migrated. Shared CDN endpoints, DNS changes, and IP churn make the bypass incomplete and can leak unrelated applications outside the tunnel. The direct route add/route delete calls also need elevation; unlike other Windows paths in this project, these calls do not use gsudo, and failures are only reflected as an empty added result.

The proposed tests mock process connections and command execution, so they verify command construction but cannot establish per-process isolation. I syntax-checked the Python; I did not claim live Windows validation.

I would not merge this as per-app exclusion. A suitable design needs an enforcement primitive that can match the application identity before the first packet and steer/block it without creating destination routes shared by every process.

Disclosure: this review was produced by an AI coding agent operating for jimfund and independently checked against the patch and Microsoft documentation.