Refuse hibernation setup on Apple T2 Macs by default

[spuder]

Fixes #9237

Problem

omarchy hibernation setup will happily configure hibernation (swapfile + resume kernel params) on Apple T2 Macs, and the System-menu Hibernate entry becomes available once it's set up. But T2 Macs don't reliably survive true hibernate (S4): the T2 controller, which also owns the internal keyboard/trackpad SPI bus, often fails to come back after resuming from a hibernation image, and the machine can hang mid-hibernate and need a hard power-off — see #9237 for a concrete case with journal evidence, and https://wiki.t2linux.org/state/ for the platform-level confirmation that hibernation isn't supported on T2.

Suspend-to-RAM (S3) is unaffected and already works on T2 via the existing t2-wifi-suspend sleep hook, so this only touches hibernation.

Fix (2 commits)

1. Block new setups. Add bin/omarchy-hw-t2, a hardware-detection helper following the existing omarchy-hw-* convention (same 106b:1801/1802 PCI-ID check already used by the other Apple T2 install fixes). omarchy-hibernation-setup now refuses by default on T2 hardware, printing an explanation and a link to the t2linux wiki. --force still allows setting it up anyway. The check sits after the "already configured" early-return, so it's a no-op for anyone who already has hibernation configured, and after the internal omarchy-system-factory-reset caller (which already passes --force) so re-provisioning an existing T2 setup after factory reset is unaffected.

Since the System-menu Hibernate entry is gated on omarchy-hibernation-available (which checks for actual swap+resume configuration), this keeps that entry hidden by default on T2 Macs too, not just the setup command — but only for machines that haven't configured hibernation yet.

2. Clean up existing setups. Commit 1 alone doesn't help anyone who already ran omarchy hibernation setup on a T2 Mac before this fix shipped — their swapfile/resume config stays in place and Hibernate stays in the menu. Add a migration (migrations/1788120123.sh) that runs omarchy-hibernation-remove on T2 hardware, reusing its own confirm prompt and no-op-when-unconfigured behavior, so it applies automatically on the next omarchy update (or via the login migration notifier for anyone who updates another way).

One-line caveat added to manual/36-system-sleep.md covering both cases.

Testing

./test/cli passes (116/116) after both commits. Manually verified on a real MacBookAir9,1 (T2):

• omarchy-hw-t2 correctly detects the hardware.
• With hibernation already removed, PATH=<checkout>/bin omarchy-hibernation-setup (no --force) prints the warning and exits without configuring anything.
• The migration script, run directly against the same machine, correctly no-ops ("Hibernation is not set up") since nothing is configured.
• omarchy-hibernation-available exits 1 (unavailable) and the System-menu Hibernate entry is gone.

No existing test harness mocks hardware detection for omarchy-hibernation-setup or migrations, so this doesn't add a new automated regression test for either — happy to add one if there's a preferred pattern for mocking omarchy-hw-* in test/cli.

🤖 Generated with Claude Code