fix(linux): consult resolvectl when resolv.conf only shows the stub (#52)

On modern Arch / Ubuntu 22.04+ / Fedora desktops, NetworkManager +
systemd-resolved symlink /etc/resolv.conf to stub-resolv.conf, which
contains only:

  nameserver 127.0.0.53

The real upstream servers (router, ISP, configured DoT providers) live
inside systemd-resolved's per-link state, exposed via 'resolvectl status'.

discover_linux() was parsing /etc/resolv.conf, correctly filtering the
stub address, and then falling through to the Quad9 DoH fallback because
detect_dhcp_dns() is macOS-only on Linux. Net effect: on a large chunk of
Linux installs, numa silently defaulted to Quad9 instead of the user's
actual DNS — visible in Casey's AUR test banner (#33) as
'Upstream https://9.9.9.9/dns-query' despite his machine having working
router DNS the entire time.

resolvectl_dns_server() already exists — it was introduced for cloud VPC
forwarding-rule discovery and knows how to ask systemd-resolved for the
real active DNS server. This commit wires it into the default-upstream
fallback chain, between the primary resolv.conf parse and the
~/.numa/original-resolv.conf backup.

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

src/system_dns.rs

@@ -228,6 +228,9 @@ fn discover_linux() -> SystemDnsInfo {
     let default_upstream = if let Some(ns) = upstream {
         info!("detected system upstream: {}", ns);
         Some(ns)
+    } else if let Some(ns) = resolvectl_dns_server() {
+        info!("detected system upstream via resolvectl: {}", ns);
+        Some(ns)
     } else {
         // Fallback to backup from a previous `numa install`
         let backup = {