`omarchy network band` can only ever offer the band you are already on when the SSID contains a non-ASCII character, and pinning any other band fails with "not available on this network".

## Why

`available_bands()` builds the list by asking two different tools for the same SSID and comparing the answers:

- `read_link()` takes the SSID from `iw dev <device> link`
- `available_bands()` takes it from `nmcli -e no -g FREQ,SSID dev wifi list`

`iw` prints an SSID through its own escaper (`print_ssid_escaped` in `util.c`): every byte that is not printable ASCII becomes `\xNN`, and so do a backslash and a leading or trailing space. `nmcli -e no` prints the raw bytes. So for `Café` the comparison is

```
name = "Café"          # nmcli
want = "Caf\xc3\xa9"   # iw
```

which never matches. The awk filter drops every scan row, `available_bands` is left with only the `$current` band it seeds itself with, and:

- the Wi-Fi band pills in the network panel show a single option
- `omarchy network band 5` (or 2.4, or 6) exits with `Error: 5GHz is not available on this network.`

The comment above `nm_get` states the premise that went wrong — it calls iw's SSID "raw" — while `decodeIwSsid()` in `shell/plugins/panels/network/Model.js` exists precisely because iw escapes SSIDs for the network list on the same panel.

## Affects

Any SSID carrying an accent, a CJK character, an emoji, a backslash, or a leading/trailing space. Plain ASCII names are unaffected, which is why this has not shown up before.

## Reproduce

Connect to a 2.4/5 GHz AP whose SSID is `Café`, then:

```
$ omarchy network band
band	5
available	5          # should be "2.4 5"
selected	auto

$ omarchy network band 2.4
Error: 2.4GHz is not available on this network.
```

`iw dev wlan0 link | grep SSID:` shows `SSID: Caf\xc3\xa9` while `nmcli -e no -g SSID dev wifi list` shows `Café`.