## What happened

Ran `systemctl hibernate` (via `omarchy hibernation setup` configured earlier) on an Apple T2 MacBook Air. The screen took a long time to turn off, then the machine hard-froze mid-hibernate — no shutdown, no resume, keyboard completely unresponsive. Had to hold the power button to force a reboot. The machine came up as a fresh cold boot rather than resuming the hibernation image (session state was lost).

## What was expected

Either hibernation works and resumes cleanly, or it's not offered/blocked on hardware where it's known not to work, so the user isn't left with a hung, unresponsive machine.

## Steps to reproduce

1. On an Apple T2 Mac, run `omarchy hibernation setup` and reboot.
2. Trigger hibernate (`systemctl hibernate`, or *Hibernate* from the System menu).
3. Wait — the screen stays on unusually long before turning off.
4. The machine never fully powers off/resumes; keyboard and screen are unresponsive. Only a hard power-off recovers it.

## Diagnostics

`journalctl -b -1` from the affected boot:

```
13:40:32 systemd-logind: hibernate requested from client PID ... ('systemctl') ...
13:40:32 systemd-logind: The system will hibernate now!
13:40:34 systemd[1]: Starting System Hibernate...
13:40:34 kernel: PM: hibernation: hibernation entry
13:41:27 kernel: Filesystems sync: 0.037 seconds     <- 53s later, and then...
```

...nothing else. The journal for that boot ends there — no shutdown target reached, no resume, no error. The next boot starts 7 seconds later as a completely fresh boot (not a resume), confirming the machine hung and was hard-power-cycled rather than cleanly hibernating.

System details (`omarchy-debug --no-sudo --print`):
- Machine: MacBookAir9,1 (2020, Apple T2 security chip)
- CPU: Intel Core i5-1030NG7 (Ice Lake)
- Kernel: 7.1.8-arch1-Watanare-T2-3-t2 (t2linux)
- Omarchy: 4.0.1-1
- `lspci -nn` shows the T2 chip at `106b:1801`/`106b:1802`

## Root cause

This is a known limitation of Linux on Apple T2 hardware, not a machine-specific fluke: the T2 chip's embedded controller (which also owns the internal keyboard/trackpad SPI bus, and the TouchBar's BCE controller on models that have one) doesn't reliably survive true hibernate (S4) — it drops power to those devices in a way the kernel can't recover from, and the machine hangs instead of cleanly powering off/resuming.

See the t2linux wiki: https://wiki.t2linux.org/state/ — hibernation is explicitly called out as not working; suspend-to-RAM (S3) is the only reliably supported sleep mode on this platform. `omarchy hibernation setup` currently has no awareness of this and will happily set up hibernation (swapfile + resume kernel params) on T2 hardware, and the *Hibernate* System-menu entry (`default/omarchy/omarchy-menu.jsonc`, guarded by `omarchy-hibernation-available`) then becomes available, so users can trigger this hang without any warning.

## Proposed fix

I'm opening a PR from my fork that makes `omarchy hibernation setup` detect T2 hardware (new `omarchy-hw-t2` helper) and refuse by default with an explanation and a link to the t2linux wiki, requiring `--force` to proceed anyway. This keeps the *Hibernate* menu entry hidden by default on T2 Macs (since it's gated on hibernation actually being configured) without touching suspend, which already works on T2 via the existing `t2-wifi-suspend` sleep hook.