### System details

ASUS ROG Zephyrus G14 GA402XV (AMD Ryzen 9 7940HS, NVIDIA RTX 4060 + AMD Radeon 780M), Omarchy 4.0.0-1, kernel 7.1.8-arch1-3, asusctl 6.3.8-1, upower 1.91.3-1. `SUPER+CTRL+P` power panel.

### What's wrong?

Two symptoms in the power panel's battery section, both traced to `omarchy-battery-status` preferring UPower over sysfs:

**1. Charge limit shows 75-80% while the real limit is 60%.**

`asusctl battery limit 60` sets the real limit:

```
$ cat /sys/class/power_supply/BAT0/charge_control_end_threshold
60
$ asusctl battery info # end threshold: 60
```
But UPower reports 75/80 and the widget shows that:
```
$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep threshold
    charge-start-threshold:   75%
    charge-end-threshold:     80%
```
Root cause: UPower imports the **udev hwdb default** `CHARGE_LIMIT=75,80` (from `/usr/lib/udev/hwdb.d/60-upower-battery.hwdb` via `/usr/lib/udev/rules.d/60-upower-battery.rules`), not the value asusctl/TLP actually set. The script reads thresholds from UPower first and only falls back to sysfs when UPower is empty, so the panel shows the hwdb default whenever it disagrees with the real limit. This affects any laptop where a tool sets a limit other than 75/80 (ASUS ROG, ThinkPads with TLP, etc.) — see e.g. Arch BBS #307781 and the systemd docs on `CHARGE_LIMIT`.

**2. "Charge cycles" shows 0, but the EC exposes no real cycle count.**
```
$ cat /sys/class/power_supply/BAT0/cycle_count
0
```
The G14 EC only implements the basic ACPI `_BIF` method (not `_BIX`), so the kernel cannot read a cycle count and reports a literal 0; UPower reports `charge-cycles: N/A`. A July 2026 kernel patch (Armin Wolf) proposes *removing* `POWER_SUPPLY_PROP_CYCLE_COUNT` for `_BIX`-only devices because the 0 is meaningless. Several ECs/drivers do this (rust-battery #23 recommends treating 0 as None). Showing "0" misleads users into thinking the battery has zero wear.

### Expected

- Charge limit reflects the real sysfs value (`charge_control_end_threshold`), falling back to UPower only when sysfs exposes none.
- Cycle count omits the misleading 0 (renders "—") when it is 0/empty; real counts still shown.

### Steps to reproduce

1. Set a charge limit that differs from 75/80, e.g. `asusctl battery limit 60` (or `tlp setcharge`).
2. Open the power panel: `SUPER+CTRL+P`.
3. Observe "Charge limit 75-80%" instead of 60%, and "Charge cycles 0".

### Diagnostics

`omarchy debug --no-sudo --print` — attach output (or `logs.omarchy.org` share link). Screenshot of the panel attached (before/after).

### Proposed fix (two atomic changes, regression-tested in `test/shell.d/battery-status-test.sh`)

1. Prefer sysfs `charge_control_end_threshold`/`charge_control_start_threshold` over UPower; fall back to UPower only when the sysfs attribute is missing; don't fabricate a start threshold without a sysfs start file.
2. Omit the `cycles` line when the value is 0/empty.