### System details

- Omarchy 4.0.4-1 (stable channel), Hyprland 0.56.2 (Wayland)
- Kernel `7.2.6-arch2-Watanare-T2-4-t2` (linux-t2)
- MacBook Pro 16-inch, 2019 (MacBookPro16,1, T2), Intel i9-9980HK (8C/16T, up to 5.0 GHz), Radeon RX 5500M + Intel UHD 630, `apple_gmux.force_igd=1`
- `powerprofilesctl`: active profile `power-saver` (CpuDriver `intel_pstate`, PlatformDriver `placeholder`)

### What's wrong?

Heavy CPU-intensive work (e.g. a big compilation) on battery cuts all power instantly: the machine goes fully dark, no clean shutdown, nothing in the journal (hard cut, not a thermal throttle or orderly poweroff). Reproducible, at least on this i9 Intel Mac.

`power-saver` does not actually cap power draw. Verified live on the machine:

- `scaling_governor=powersave`, `EPP=power`, but `scaling_max_freq=5000000` (all policies), `intel_pstate/max_perf_pct=100`, `no_turbo=0`
- RAPL `package-0`: `long_term=45000000` (45 W, ~28 s window), `short_term=0` (uncapped, 2.4 ms window)
- `powerprofiles-daemon` exposes only the `trickle_charge` action — EPP hint only, no frequency/RAPL enforcement on this hardware

At the time of the cut the machine was on battery: `ADP1 online: no`, ~51%, `~27.8 W` idle, `~10.85 V` (below the 11.4 V design minimum). Under full i9 turbo plus the known ~15–18 W dGPU idle drain (mclk pinned despite `force_igd`, per the T2 limine config comment), total draw spikes to ~70 W+ from the battery alone, then the BMS/SMC cuts power. Previous boot in `journalctl --list-boots` ends with a clean systemd unmount sequence (a reboot, not the cut); the cut itself leaves no log, consistent with protection circuitry.

Battery itself looks healthy (`BAT0`: 34 charge cycles, capacity 100%, energy-full ~100 Wh vs ~99 Wh design), so this is not a worn-battery shutdown — it is full turbo draw on battery with no cap.

### What was expected?

On battery (or at least under `power-saver`), sustained/spike CPU draw is capped so a big compile throttles instead of killing the machine — e.g. no-turbo and/or a lower RAPL limit — or the docs warn that heavy loads require AC on this hardware.

### Steps to reproduce

1. Unplug (confirm `ADP1 online: 0`), confirm `powerprofilesctl get` → `power-saver`.
2. Run a heavy parallel compile / CPU stressor.
3. Machine cuts all power abruptly; reboot and observe no matching error in `journalctl -b -1` (prior boot ends cleanly).

### Diagnostics collected

- `lscpu`: i9-9980HK, 16 CPUs, max 5 GHz, min 800 MHz
- `cat /sys/devices/system/cpu/intel_pstate/{max_perf_pct,no_turbo}` → `100`, `0`
- `cat /sys/class/powercap/intel-rapl:0/constraint_{0,1}_{max_power_uw,name}` → `45000000/long_term`, `0/short_term`
- `upower` battery/line-power excerpts as above; idle temps ~50 °C, fans ~1700 RPM (no thermal trip; throttle point is 100 °C)
- Boot log shows the usual T2 noise (ACPI `AE_ALREADY_EXISTS`, `MCE Bank 12/13 ee2000000040110a`, `intel-lpss` probe fail, missing `BCM.hcd` for Bluetooth) — included for completeness, likely unrelated to the load cut.
- Note: `omarchy debug --no-sudo --print` from the contributing guide does not exist in 4.0.4-1 (`Unknown Omarchy command`), so diagnostics above were gathered manually. Also `basecamp/omarchy` now redirects to `omacom/omarchy`.

### Suggested direction (for maintainers to decide)

Whether a battery-mode CPU cap (e.g. `no_turbo=1` and/or RAPL ~25 W long-term on `power-saver`/battery, restored on AC) belongs in Omarchy defaults, or whether this should just be documented T2 behavior. Happy to test a patch. I have a local udev-rule workaround drafted (`ATTR{type}=="Mains"` toggling `no_turbo` + RAPL) but have not applied it yet.