### What happened

MacBook Air (13-inch, Mid 2012) (1.0)

The `omarchy.network` bar widget drives NetworkManager `RequestScan` calls while the network
panel is closed. On hardware where a scan is slow this causes continuous, measurable packet
loss. There are two severities:

1. **Normal operation** — roughly one `RequestScan` every ~150s. Costs ~4.4% packet loss here.
2. **Stuck state** — the widget gets stuck scanning **every 10 seconds indefinitely**. Costs
   ~19.7% packet loss. Seen after several hours of uptime; `omarchy restart shell` clears it,
   but it returned within a few hours.

Removing `omarchy.network` from the bar layout eliminates both: **0 scans and 0% loss over
750 pings / 150s**. Re-adding it brings the loss back. That isolates the widget as the cause.

On a slow-scanning card this is destructive rather than cosmetic. This machine has a
Broadcom BCM43224 on `brcmsmac`, where one full 37-channel scan takes **~11 seconds**. A
scan every 10s meant the radio was off its associated channel roughly **half the time**,
so it missed inbound frames continuously:

| Bar config | Scans | Packet loss to gateway |
|---|---|---|
| Widget present, stuck state | ~4.5 / 90s | **19.7%** (900 pings) |
| Widget present, normal | 1 / 90s | **4.4%** (450 pings) |
| **Widget removed from bar** | **0 / 150s** | **0%** (750 pings) |

Signal was -46 dBm with zero beacon loss and only +2 tx retries per 100 pings throughout,
so this was not RF, roaming, or the transmit path.

### Evidence

`RequestScan` caller identified on the system bus, panel closed:

```
method call sender=:1.48 -> destination=org.freedesktop.NetworkManager
  path=/org/freedesktop/NetworkManager/Devices/2
  interface=org.freedesktop.NetworkManager.Device.Wireless; member=RequestScan
```

`:1.48` resolved via `GetConnectionUnixProcessID` to:

```
PID  PPID USER  CMD
944  941  <user> quickshell -n -p /usr/share/omarchy/shell
```

Timestamps show a strict 10s cadence: `...639.07`, `...650.17`, `...660.17`.

Correlating `iw event -t` with a ping run, the loss window falls exactly inside each scan:

```
1787485269.570971: scan started
1787485280.625887: scan finished: 2412 2417 ... 5805 5825   <- 11.05s, 37 channels
```

Over a 180s sample: 8 scans, durations `[11.1, 11.1, 11.0, 11.1, 11.0, 10.9, 11.0, 10.8]`,
totalling 88.0s of 180s = **49% off-channel**.

### Expected

With the network panel closed, the bar widget should not trigger Wi-Fi scans at all. A bar
icon showing connection state and signal does not need a fresh AP list; that is only needed
while the panel is open. Scanning is not free on every radio.

### Reproduction

The *baseline* behaviour reproduces reliably: add `omarchy.network` to the bar and scans
resume; remove it and they stop. **The 10-second stuck state I could not reproduce on demand** —
it appeared after hours of uptime, and returned after an `omarchy restart shell` had cleared it.
Toggling the panel open and closed (`omarchy-shell shell toggle omarchy.network`) correctly
releases the scanner — 0 scans in the following 45s. The state appeared after several hours
of uptime. `omarchy restart shell` clears it reliably.

`setScannerEnabled` in `shell/plugins/panels/network/Panel.qml` looks correct on the normal
path (`var nextDevice = opened ? wifiDevice : null`, plus release in `onOpenedChanged` and
`Component.onDestruction`). The suspect is therefore a path that leaves `scannerEnabled` true
on the shared `WifiDevice` without an owning open panel — note the comment there that the
property "has no reference counting, and a bar widget is instantiated once per monitor".
A monitor hotplug / device replacement / suspend-resume ordering seems the likeliest cause.

Two things that might make this class of bug harmless regardless:
- reference-count `scannerEnabled` on the shared `WifiDevice`, and/or
- have the scanner auto-expire rather than scan forever while nothing is watching.

### Ruled out

- **UFW** — 0 ICMP blocks during a test that lost 18%. The `[UFW BLOCK]` TCP ACK lines in the
  log are a *symptom* (stalled connections' late ACKs falling outside conntrack), not a cause.
- **wpa_supplicant `bgscan`** — `simple:30:-70:86400`; RSSI was -44, above the -70 threshold,
  so it was in its 24h mode.
- **Wi-Fi power saving** — already off.

### Environment

- Omarchy 4.0.0-1
- quickshell-git 0.3.0.r20.g28771c7-2
- NetworkManager 1.58.0-1
- Kernel 7.1.8-arch1-3
- Broadcom BCM43224 / `brcmsmac`, MacBookAir5,2

### Unrelated minor finding

`omarchy debug --no-sudo --print` fails with `Unknown Omarchy command: omarchy debug`,
though `omarchy --help` advertises it and the `omarchy-debug` binary accepts those flags.
The dispatcher route appears to be missing. Happy to split this into its own issue.