Add graceful low-battery shutdown with a reserved charge display

[malik-na]

Adds a battery guard that starts a 60-second shutdown countdown at 5% hardware charge, or when estimated runtime is critically short. The desktop and battery-status command show a consistent usable-charge scale, with 5% hardware charge displayed as 1%.

The countdown updates one notification. During its final 15 seconds, the guard requests normal application window closes before standard systemd poweroff. Persistent deadlines and per-window attempts prevent restarts from extending the countdown or repeatedly dismissing save dialogs. Confirmed charging cancels the countdown. Includes package-backed setup and migrations for new and existing installs.

No session restore is attempted. Users must save their work; application close requests cannot guarantee unsaved-data preservation. The guard does not protect against battery drain while suspended.

Validation: focused battery, deployment, mapping, metadata, and syntax checks passed, along with independent review. A native disposable-window close test passed, and visual verification confirmed percentage alignment and one updating countdown notification. Full CLI suite passed; 258/259 shell test files exited successfully, with 17 coverage skips. The sole aggregate failure was unchanged network-QR behavior under sandbox netlink restrictions.

The earlier guard completed a real discharge shutdown. This revised 5% version is installed and running locally for the current boot; its next real discharge test remains pending.

[duketopceo]

Verified on MacBookPro18,1 (M1 Pro, aarch64, macsmc-battery), Omarchy 4.0.3-1:

• All new shell tests pass: battery-guard-test, battery-guard-close-test, battery-guard-deployment-test, battery-status-test, battery-usable-test.
• Live --oneshot dry-run against real sysfs while discharging (65%, no AC): detected the battery, entered countdown, and persisted correct state (mode=countdown, uptime-based deadline, boot id) — no shutdown, nothing dispatched.
• Read through the daemon: the careful parts check out — power_recovered is re-polled at every action boundary (handles weak-adapter-still-discharging), close-request markers persist before dispatch so a restart can't re-fire a save dialog, deadlines shorten but never extend, and shutdown uses the normal systemctl poweroff transaction (no force, no PID kills).

The multi-user loginctl/runuser fan-out and the QML reserve-display changes are reviewed-by-reading only — single-user session here so I could not exercise a second seat. LGTM overall.