UDP socket binding fails on Windows when dual-stack/VPN active (wsasendto: invalid context) #134

Describe the Bug

When running olm on Windows alongside a secondary system VPN (such as Proton VPN), the daemon fails to establish a P2P holepunch or UDP connection.

During socket initialization, the Go network stack selects a local IPv6 source address (e.g., from a virtual/tunnel adapter) to target an IPv4 destination address (the exit node). This causes wsasendto on Windows to fail with The requested address is not valid in its context..

Even with "disableHolepunch": true set in the configuration, initial UDP holepunch packets still attempt to bind and send via the wrong interface, causing connection failures.

Environment

Environment

• OS: Windows 10 / 11
• Olm Version: 1.8.2
• Co-existing Software: Proton VPN (or other Wintun / Dual-Stack VPN interfaces)

To Reproduce

Steps to Reproduce

1. Start Proton VPN (or any similar Wintun/BFE-based VPN) on Windows.
2. Launch olm daemon.
3. Observe HOLEPUNCH_MISSING and wsasendto socket error logs.

Relevant Logs

INFO: Created shared UDP socket on port 61377 (refcount: 2)
INFO: Starting hole punch for 1 exit nodes
WARN: Failed to send initial hole punch to gate.example.com: failed to write to UDP: write udp [fd00::1234:5678]:61377->203.0.113.10:21820: wsasendto: The requested address is not valid in its context.
ERROR: Olm error (code: HOLEPUNCH_MISSING): Unable to coordinate client P2P connection. Please ensure your client can reach the server on UDP port 21820 and try registering again.

### Expected Behavior

1. IPv4 Binding Option / Fix: Provide an option in config.json (or automatically handle in code) to force binding listeners/sockets to IPv4 (0.0.0.0) or filter out IPv6 source IPs when targeting IPv4 endpoints.
2. Strict disableHolepunch Handling: Ensure that setting "disableHolepunch": true completely suppresses initial UDP holepunch attempts to prevent socket binding errors when P2P UDP is blocked/incompatible with host adapters.