[Feature]: Allow configuring WireGuard interface metric on Windows

### Problem description

Currently, when connecting to a VPN using Defguard client on Windows, the created network interface is assigned a very low metric (e.g. 5). This causes Windows to prioritize the VPN interface for all outbound traffic, including DNS resolution.

In environments where split DNS is required, this behavior creates issues:

* Even when using NRPT (Name Resolution Policy Table) for specific domains (e.g. Active Directory zones), all other DNS queries are still resolved using the VPN-provided DNS server due to interface priority.
* This overrides local DNS infrastructure (e.g. local AdGuard or internal resolvers) and makes it difficult to maintain proper split DNS behavior.
* Windows does not provide a reliable way to override the default DNS selection for “non-NRPT” queries.

**Use case:**

* Local network provides DNS (e.g. AdGuard) for general and custom domain resolution.
* VPN DNS should only be used for specific domains (e.g. `corp.local`).
* Users need access to both:

* local network name resolution
* VPN/AD name resolution
* public DNS via local resolver

**Current limitation:**
Defguard enforces a low interface metric on the WireGuard adapter, effectively forcing all DNS traffic through the VPN DNS unless workarounds (scripts, manual metric changes, or separate profiles) are used.

---

Thank you for considering this feature.

### Proposed solution

Please add one (or more) of the following options:

1. **Configurable interface metric for the WireGuard adapter on Windows**

* Allow setting a custom metric (e.g. via UI or configuration)
* Example: set metric to a higher value than local interfaces

2. **Option to not override / not prioritize the VPN interface**

* Let Windows default routing/metric behavior apply

3. (Optional, advanced) **Support for split DNS configuration**

* Ability to define domains that should use VPN DNS (similar to NRPT behavior)

**Benefits:**

* Proper split DNS without hacks or scripts
* Better integration with existing local DNS infrastructure
* Avoids breaking local name resolution when VPN is active
* More flexibility for advanced and enterprise setups

**Additional context:**
This is especially important in mixed environments where users run local services (e.g. homelab, local DNS, reverse proxies) alongside corporate VPN access.

### Alternatives considered

_No response_

### Impact

Nice to have