## What happened

On a MacBook5,1 with an Apple Broadcom BCM4322 adapter, Omarchy uses the
in-kernel `b43` driver. Networks are visible, but after a warm reboot the
adapter intermittently fails to remain connected. A full shutdown/power-on
usually restores it.

Hardware:

```text
03:00.0 Network controller: Broadcom BCM4322 802.11a/b/g/n [14e4:432b] (rev 01)
Subsystem: Apple Inc. AirPort Extreme [106b:008d]
Machine: Apple MacBook5,1
```

Observed with Omarchy 4.0.3-1 and Linux 7.2.3-arch1-3. In a failed boot,
`b43` reports:

```text
Fatal DMA error: 0x00000400
This device does not support DMA on your system. It will now be switched to PIO.
PREV_AUTH_NOT_VALID
```

Forcing `b43` to PIO from the initramfs (also with `nohwcrypt=1`) removes the
DMA error but does not prevent disassociation. PCI reset, PCI remove/rescan,
suspend/resume, and disabling ASPM did not solve the warm-reboot failure.

## Workaround verified on this machine

Installing the official Arch package `broadcom-wl-dkms` and ensuring `wl` is
the first driver to initialize the adapter fixed the functional problem in
the initial test series:

```text
/etc/mkinitcpio.conf.d/wifi-wl-first.conf:
MODULES+=(wl)
```

The package-provided `/usr/lib/modprobe.d/broadcom-wl-dkms.conf` blacklists
`b43`, `ssb`, and the other conflicting Broadcom modules. After rebuilding
the UKI, the result was:

- one successful cold boot;
- three consecutive successful warm reboots;
- automatic WPA connection and DHCP on every boot;
- Internet traffic explicitly tested over the Wi-Fi interface with 0% loss;
- no `Fatal DMA error` or `Scan_results error (-22)`.

Loading `wl` only after `b43` had already initialized the card produced
`Scan_results error (-22)` and misleadingly looked like a `wl` failure. This
same driver-order behavior is documented for the identical PCI ID in Debian
bug #1088231:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088231

## Suggested Omarchy change

`install/hardware/fix-bcm43xx.sh` currently handles BCM4360 (`14e4:43a0`)
and BCM4331 (`14e4:4331`) by installing `broadcom-wl-dkms`, but not BCM4322
(`14e4:432b`).

Could BCM4322 support be documented or offered as an explicit opt-in hardware
workaround, including rebuilding the initramfs/UKI so `wl` initializes the
adapter before `b43`? I would avoid enabling it unconditionally based only on
the PCI ID: Broadcom behavior varies by Mac model, and issue #7593 documents
a BCM4331 machine where `wl` causes hard freezes.

## Important caveat

This is a functional workaround, not an endorsement of the proprietary
driver. On Linux 7.2.3, `wl` emits warnings that it is unmaintained and
incompatible with kernel security mitigations, plus `Unpatched return thunk`
and a FORTIFY `field-spanning write` warning in
`wl_cfg80211_hybrid.c`. Any Omarchy integration should present that tradeoff
clearly and preferably remain opt-in.