### System details

Omarchy `4.0.0-1` (Arch) · Intel Pentium Silver N5030 · Wi-Fi 6 AX200 (`wlp2s0`) + Realtek RTL8111 (`enp3s0`) · Wi-Fi SSID `osarchy` · CloudflareWARP VPN

### What's wrong?

The network panel hero reads **"Ethernet (10gbit)"** while the machine is actually on Wi-Fi, and the IP shown is the WARP tunnel IP (`172.16.0.2`) instead of the Wi-Fi IP (`10.42.0.148`). SSID/gateway are empty. The bar icon is correct (Wi-Fi glyph, from the Quickshell NetworkManager backend via `Panel.qml` `kind`), so only the panel header/details — fed by `omarchy-network-status` — are wrong.

### Root cause

`bin/omarchy-network-status` selects the active interface from the **route table** via `ip route get 1.1.1.1`, not from NetworkManager. CloudflareWARP installs a policy-routed default route (`fwmark 0x100cf → table 65743`) that captures that probe, so `iface` resolves to `CloudflareWARP`. Because the tun has no `/sys/class/net/CloudflareWARP/wireless`, the script classifies it `type=ethernet`, and `/sys/class/net/CloudflareWARP/speed` reports a bogus `10000` Mbps → `formatHeaderSpeed(10000)` renders `"10gbit"` (Model.js). `Panel.qml` then keys the hero off `info.type`/`info.speed` and shows `info.ip`.

Note `bin/omarchy-network-band` already does this correctly — it selects the connected device from `nmcli device status` (`TYPE == wifi`) instead of the route table.

### Steps to reproduce

1. Connect to Wi-Fi (`wlp2s0`, any SSID).
2. Start CloudflareWARP (or any VPN whose `tun` wins the default route, e.g. WireGuard `AllowedIPs = 0.0.0.0/0`).
3. Open the network panel (Wi-Fi icon in bar, or `SUPER+CTRL+W`).
4. Observe hero "Ethernet (10gbit)" and IP `172.16.0.2`.

### Diagnostics

```
$ ip route get 1.1.1.1
1.1.1.1 dev CloudflareWARP table 65743 src 172.16.0.2 uid 1000

$ ip rule
0:	from all lookup local
32765:	not from all fwmark 0x100cf lookup 65743
32766:	from all lookup main
32767:	from all lookup default

$ omarchy-network-status --verbose
iface	CloudflareWARP
ip	172.16.0.2
type	ethernet
speed	10000
duplex	full

$ ls -d /sys/class/net/CloudflareWARP/device   # does not exist (virtual iface)
$ cat /sys/class/net/CloudflareWARP/speed      # -> 10000
$ ls -d /sys/class/net/wlp2s0/wireless         # -> exists
$ ls -d /sys/class/net/enp3s0/device           # -> exists (physical NIC)
```

### Suggested fix

After resolving the route's `iface`, if it is not a real NIC (`/sys/class/net/$iface/wireless` **and** `/sys/class/net/$iface/device` both absent → virtual `tun`/`tap`/`vpn`), re-resolve from NetworkManager:

```sh
LC_ALL=C nmcli -t -f DEVICE,TYPE,STATE device status \
  | awk -F: '$2 == "ethernet" && $3 == "connected" { print $1; exit }'
# fallback:
LC_ALL=C nmcli -t -f DEVICE,TYPE,STATE device status \
  | awk -F: '$2 == "wifi" && $3 == "connected" { print $1; exit }'
```

Ethernet first, to match the panel's `kind` precedence. When the probe route's dev differs from the physical `iface`, derive gateway from the physical device's default route (`ip -j route show dev <iface> default | jq -r '.[0].gateway // ""'`), and report `speed`/`duplex` for real NICs only.

> Filed by deepseek-v4-flash-free via opencode.