### System details

Intel i7-4770HQ, Intel Iris Pro (Crystal Well), MacBookPro11,4 (Mid-2015 15"), BCM43602 `[14e4:43ba]` (Apple subsystem `106b:0152`) on `brcmfmac`, firmware `7.35.177.61` from `linux-firmware-broadcom 20260810-2`, no NVRAM/CLM blob, Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy

### What's wrong?

`install/hardware/set-wireless-regdom.sh` sets the regulatory domain from the timezone. With `Europe/Kyiv` it writes `WIRELESS_REGDOM="UA"` to `/etc/conf.d/wireless-regdom`, and wireless-regdb's `85-regulatory.rules` applies it on every boot. **On this BCM43602 firmware, when `UA` is the user regdomain at the moment `brcmfmac` loads, the adapter loses 802.11ac completely.** `iw list` has no VHT lines, Band 2 shows `Capabilities: 0x1062` (HT40, no VHT), and the Mac stays on 2.4 GHz at 802.11n/g rates.

For each value: `iw reg set <cc>`, reload `brcmfmac`, count VHT lines, then force a join to the 5 GHz BSSID (`nmcli connection up id <ssid> ap <5 GHz BSSID>`):

| User regdom at driver load | `iw list \| grep -c VHT` | Joins the 5 GHz AP |
|---|---|---|
| **UA** (tested twice) | **0** | – |
| US | 6 | yes (5300 MHz, ch 60) |
| DE | 6 | yes (5300 MHz, ch 60) |
| 00 (world) | 6 | **no**: `ASSOC-REJECT status_code=16` (world domain marks 5 GHz no-initiate) |

- Changing the regdomain **after** the driver has loaded doesn't help. `iw reg set US/DE/00` on a live driver left VHT at 0. Only a reload under a non-`UA` regdomain brings it back.
- This doesn't depend on NetworkManager. With NetworkManager and wpa_supplicant stopped, a reload under `UA` still gave VHT=0 for the whole polling window.
- The `feature_disable` value doesn't change it either. Under `UA`, VHT is missing with both `0x82000` and `0`.

### Correction to #13164

I now think the missing VHT I reported in #13164 was caused by this regdomain issue, not by the `feature_disable=0x82000` quirk. My warm reloads with `feature_disable=0` brought VHT back only because an earlier `iw reg set` experiment had left the user regdomain at something other than `UA`. On the next boot udev set `UA` again, and VHT was gone however many times I reloaded. Under a non-`UA` regdomain, a reload with `0x82000` **does** show VHT. That matches the MacBookPro11,5 datapoint in the #13164 comments. In that one run the card associated on 2.4 GHz instead of 5 GHz, but I didn't repeat the test with a band pin. Whether the quirk itself blocks 5 GHz on a WPA2/WPA3 transition network is not confirmed yet.

### Steps to reproduce

1. BCM43602 Mac with stock firmware and no CLM blob. Install Omarchy with timezone `Europe/Kyiv`, so `/etc/conf.d/wireless-regdom` contains `WIRELESS_REGDOM="UA"`.
2. Boot, then run `iw list | grep -c VHT`. It prints `0`.
3. `sudo iw reg set DE && sudo modprobe -r brcmfmac_wcc brcmfmac && sudo modprobe brcmfmac`, then run `iw list | grep -c VHT`. It prints `6`.
4. `sudo iw reg set UA && sudo modprobe -r brcmfmac_wcc brcmfmac && sudo modprobe brcmfmac`, then run `iw list | grep -c VHT`. It prints `0`.

### Verified workaround

Replace the derived value in `/etc/conf.d/wireless-regdom`:

```
WIRELESS_REGDOM="DE"
```

DE uses the EU/ETSI rules, the closest to Ukraine's. US also works. `set-wireless-regdom.sh` exits early when a `WIRELESS_REGDOM=` line already exists, so the change survives updates. It has held across reboots for two weeks: `iw list | grep -c VHT` = 6, and the Mac is associated to the 5 GHz BSSID at 5260 MHz. (The Country IE mitigation from #13168 is also in place on this machine. That one is a separate failure, where the link drops within a minute of joining.)

### Possible fix

- In `set-wireless-regdom.sh`, or in an Apple Broadcom quirk next to `fix-brcmfmac-supplicant.sh`: on BCM43602 (`14e4:43ba`), when the derived country is one this firmware mishandles (`UA` is confirmed), write a working country from the same regulatory family instead, such as an ETSI country, with a comment explaining why.
- Don't fall back to `00`, because it blocks 5 GHz association on this firmware.
- I only tested UA, US, DE and 00. Other countries may be affected too. A BCM43602 NVRAM/CLM file (#7672) might make the firmware accept `UA`, but I haven't tested that.

Related: #13164, #13168, #9019, #7672