Prefer active Wi-Fi over a TUN default route in the bar

[Chessing234]

Summary

• omarchy-network-status took the ip route get device literally, so a TUN/VPN path was reported as ethernet and the bar hid the live Wi-Fi SSID.
• When the route device is not wireless, prefer a NetworkManager Wi-Fi device that is already connected.

Fixes #9624

Test plan

• With Wi-Fi up and a TUN default route, omarchy-network-status prints wifi and the SSID
• Plain ethernet (no Wi-Fi) still reports ethernet
• Disconnected still reports disconnected

[omarchybot]

Reviewed against quattro (merge-base b71dcad, head 6d89c58) by Claude Opus 5 in Claude Code, with an independent second opinion from Codex at xhigh reasoning. Everything below was run on a disposable VM, never on this machine. Where the two reviews agree that is said plainly — Codex's independence is not currently guaranteed, so agreement is worth less than the measurements.

What it fixes. The reported case works. With a TUN device owning the route to 1.1.1.1 and NetworkManager reporting a connected Wi-Fi device, omarchy-network-status now names the Wi-Fi device instead of the tunnel.

The rule is wider than the title says. There is no tunnel test in the diff at all: the substitution at bin/omarchy-network-status:35 fires for any route device without a wireless sysfs directory, and a tunnel is only one member of that set. On a VM with a real Ethernet default route and an nmcli stub reporting wlp3s0:wifi:connected:

base : ethernet  ens18
9652 : ethernet  wlp3s0

ens18 is the interface actually carrying the traffic. That VM has no /sys/class/net/wlp3s0/wireless, which is the only reason the first field stayed ethernet; on a real laptop the same path falls through to the Wi-Fi branch and prints wifi <SSID> <signal> <freq>. So a docked laptop with Wi-Fi still associated would show the SSID and signal bars of a radio carrying none of its packets. Bonds, bridges, VLANs, USB tethering and WWAN links land in the same set (Codex's list; the mechanism is the same one measured above).

Two narrower points on the same line. The awk match is /^connected/, so connected (local only) — an association with no internet — is accepted as the device to advertise. And nothing ties the chosen Wi-Fi device to the tunnel: a VPN carried over Ethernet on a machine with an incidental Wi-Fi association reports that Wi-Fi.

--verbose is untouched, and that is the panel's data source. print_verbose resolves the route again on its own at bin/omarchy-network-status:103, so with a TUN route it still prints iface <tunnel> and type ethernet — measured on the VM. shell/plugins/panels/network/Panel.qml:812 reads exactly that output, so the panel's detail view is unchanged by this PR. Worth knowing either way: the bar pill's own icon comes from NetworkManager at Panel.qml:435 and never runs this command, so the pill is not what this diff moves. The consumers it does move are the Wi-Fi QR entry in default/omarchy/omarchy-menu.jsonc:135 and the speed test title at shell/plugins/panels/speedtest/Panel.qml:174 — both of which would now say Wi-Fi on an Ethernet-primary machine.

Tests. No test ships with this PR. On the worker I ran test/shell.d/network-test.sh (104 ok), network-qr-test.sh (7 ok), network-manager-transition-test.sh (3 ok) and test/cli (116 ok, exit 0): all green, but none of them exercise this script's device selection, so green says nothing about the change. The comparisons above are what was actually measured.

Nothing was pushed to your branch. #9666 fixes the same issue (#9624) with a different rule, so this is two designs for one behaviour rather than one being a correction of the other, and which one lands is the maintainer's call — neither PR is being closed or edited here. The Ethernet-plus-Wi-Fi substitution above is worth answering whichever way that goes.