Binding to specific interfaces/IPs for outgoing connections

This issue has been touched upon a couple times, but I thought I should make it a bit clearer with my use case, and ask for comments on feasibility.

Use case: Win10 system with fast (but metered) wired connection (LAN) and slower but essentially unlimited wifi (WF), both behind NAT. There is no port forwarding/UPnP, but remote nodes do have it so direct connections work on both. Interface and gateway (route) metrics are such that everything goes to LAN by default but I want ST to use WF exclusively to save on traffic.

Problem 1: setting listen IP to $WF_IP$ does work but only for listen connections...global discovery/outgoing connections still go out LAN (as expected due to OS routing) and so does all the traffic that follows. (there is also a problem with discovery server not auto-adding source IP anymore, but that is intended as per v3 protocol specs)

Problem 2: even if setting outgoing IP was possible, $WF_IP$ changes frequently - hardcoding it is useless

Desired feature: ability to pick interface and (optionally) specific IP to bind to for all internet traffic (global discovery/relay/direct connections). For example, something like in qBitTorrent:

Note that IP binding is useful since single interface can have multiple IPs due to aliases (in my case, main IP is 10.1.1.10 and there is IP alias 10.1.1.11 with 'SkipAsSource=true', such that applications that specifically bind to it are routed over VPN but other traffic only uses 10.1.1.10).

In case both options are not selected, ST should defer to default OS routing as it does now. If only interface is specified, it should follow system routing behavior for that interface (if not known/hard, just pick single IP like libtorrent does). Option to choose fallback strategy in case of interface/IP being unavailable is necessary.

Besides my use case, there are other ways this can be useful. For example, to prevent flip-flopping over intermittent connections (wi-fi or cellular modem/tether), to limit sharing to home IP, or to route ST traffic over VPN interface.

No files, tests, or entry points are named in the issue. Start by tracing how Syncthing creates listen, discovery, relay, and direct outgoing connections, then determine how interface or IP selection and unavailable-interface fallback would apply across those paths; done means all requested traffic respects the selected binding while default routing remains unchanged.