fix(optimize): narrow VPN detection to scutil + default route

The previous has_active_vpn_interface treated any UP utun* interface (or
a utun row in the IPv4 routing table) as proof that a VPN was active.
macOS uses utun* extensively for non-VPN features: iCloud Private Relay,
Continuity, Handoff, AirDrop, Apple Watch sync, Personal Hotspot. A
Mac that simply has Private Relay enabled was permanently flagged as
"VPN active" and the Network Stack Refresh step short-circuited, even
when the user's actual VPN client was disconnected (#959).

Replace the bare interface probe with two narrower signals:

1. `scutil --nc list` exposes system-managed VPN connections (L2TP,
   IPsec, IKEv2, Cisco IPSec) and tags the live one with
   "* (Connected)". Match on that prefix only.
2. `route -n get default` returns the interface owning the default
   route. When that interface is utun*, a full-tunnel third-party VPN
   (WireGuard, OpenVPN, Tunnelblick) is routing all traffic.

Split-tunnel third-party VPNs that do not own the default route are no
longer detected. A subsequent `sudo route -n flush` may briefly drop
their explicit routes, which the VPN client re-establishes on its next
reconcile. This is a controlled regression for that smaller cohort
in exchange for unblocking the much larger Private Relay cohort.

MOLE_ASSUME_VPN_ACTIVE remains an explicit override for both directions.

Tests cover six paths: both env override values, scutil Connected,
scutil-only-Disconnected, utun-default-route full tunnel, and the
specific iCloud Private Relay false-positive scenario from #959.