## What happened

On a T2 MacBook (MacBookPro15,4, i5-8257U), closing the lid never actually suspends. `systemd-logind` starts a suspend, it fails within ~12 seconds, and logind immediately retries — over and over. Over one hour with the lid closed, the machine attempted to suspend **115 times** and never actually slept once. The screen was off the whole time, so from the lid it looked like it had hibernated; in reality the CPU stayed fully awake the entire hour, which is why the battery drains far faster than it should.

## Root cause

The kernel log at every attempt shows the same failure, from the PCIe Wi-Fi driver:

```
brcmfmac 0000:01:00.0: brcmf_pcie_pm_enter_D3: Timeout on response for entering D3 substate
brcmfmac 0000:01:00.0: PM: pci_pm_suspend(): brcmf_pcie_pm_enter_D3 [brcmfmac] returns -5
brcmfmac 0000:01:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -5
brcmfmac 0000:01:00.0: PM: failed to suspend: error -5
PM: Some devices failed to suspend, or early wake event detected
```

The BCM4377b PCIe Wi-Fi chip times out responding to the D3 power-state request, `brcmfmac`'s `.suspend()` callback returns `-EIO`, and the kernel aborts the entire suspend and resumes every device. `systemd-sleep` then reports:

```
systemd-sleep[…]: Failed to put system to sleep. System resumed again: Input/output error
```

`systemd-suspend.service` fails, and whatever asked for suspend (lid close, `systemctl suspend`) just gets called again, so this repeats indefinitely.

## Reproduction

- Hardware: MacBookPro15,4 (2019 13", i5-8257U, T2 chip), Wi-Fi is `Broadcom BCM4377b` (`14e4` behind the T2, PCIe-attached, driven by `brcmfmac`)
- `uname -r`: `7.1.8-arch1-Watanare-T2-3-t2` (linux-t2)
- Omarchy version: 4.0.0-1, stable channel
- Steps: close the lid (or run `systemctl suspend`) on affected hardware. Watch `journalctl -b -k -f` — the D3 timeout and `PM: suspend exit` appear within seconds, and `journalctl -u systemd-logind` shows the retry loop.

## Fix

Unloading `brcmfmac`/`brcmfmac_wcc` before suspend and reloading it on resume avoids the broken D3 handshake entirely — this is the standard workaround used elsewhere for this chip family. I tested this on the affected machine: without the fix, every suspend attempt fails the same way within ~12 seconds; with a `pre`/`post` `systemd-sleep` hook doing the unload/reload, suspend completes cleanly (kernel stays asleep for the full duration, e.g. 28s in one test), Wi-Fi reconnects automatically on resume, and there is no D3 timeout in the log.

I've opened a PR (#TBD) adding this as a hardware-conditional `/usr/lib/systemd/system-sleep/` hook, gated on the T2 PCI ID the same way `fix-t2.sh` and `fix-brcmfmac-supplicant.sh` already are, plus a migration so existing T2 installs pick it up without a reinstall.

## Diagnostics

`omarchy debug --no-sudo --print` isn't available on 4.0.0-1 (`Unknown Omarchy command`); happy to attach whatever diagnostic format is preferred.