## What happens

Nothing in the battery panel reads `charge_control_end_threshold`, so when a
charge limit is set on the hardware, the panel misreports it in two different
ways depending on the state of charge.

**1. A cap on a nearly full battery is reported as no cap at all.**

`Model.chargeThresholdActive()` infers whether a limit is in force from the
charge level and the UPower state rather than reading the threshold:

```js
if (d.state === s.FullyCharged && fraction < 0.99) return true
if (d.state !== s.Charging || fraction >= 0.99) return false
```

With the battery at 99% and a 60% cap applied, the state is `FullyCharged` and
the fraction is not below 0.99, so the second line returns false. The panel
shows "FULLY CHARGED" with "Time to full" and "Charging" rows, and no charge
limit row, while the firmware is holding a 60% cap and refusing to charge.

This is the normal state right after a limit is lowered, because lowering a cap
stops charging but does not discharge the battery. It can persist for days on a
machine that stays on mains.

**2. When the panel does show a limit, the number comes from UPower and is not
the one in force.**

`omarchy-battery-status` reads the threshold from UPower and falls back to
sysfs only when UPower returns nothing:

```bash
threshold_start=$(awk '/charge-start-threshold:/ ...' <<<"$battery_info")
threshold_end=$(awk '/charge-end-threshold:/ ...' <<<"$battery_info")

[[ -z $threshold_end ]] && threshold_end=$(cat "$power_supply_path"/BAT*/charge_control_end_threshold ...)
```

UPower always returns something here, so the sysfs fallback is unreachable. On
this machine UPower reports a 75-80% pair alongside
`ChargeThresholdEnabled = false`. Those are the values UPower would apply if
something called `EnableChargeThreshold`, not a reading of the hardware.

## Steps to reproduce

On a laptop whose kernel driver exposes `charge_control_end_threshold`, an ASUS
Zenbook with `asus_nb_wmi` in this case:

```bash
# Set a cap well below the current charge
echo 60 | sudo tee /sys/class/power_supply/BAT0/charge_control_end_threshold

cat /sys/class/power_supply/BAT0/charge_control_end_threshold   # 60
cat /sys/class/power_supply/BAT0/status                         # Not charging

# UPower does not agree, and never did
upower -i /org/freedesktop/UPower/devices/battery_BAT0 | grep charge-
#     charge-start-threshold:        75%
#     charge-end-threshold:          80%

omarchy-battery-status --shell | grep threshold
# threshold	75-80%
```

Then open the battery panel. At 99% charge it reports "FULLY CHARGED" with no
charge limit row.

## Evidence that UPower is not reading the hardware

The 75-80% pair is not a stale cache. It does not track the hardware at all.
Driving the threshold through three values leaves UPower unchanged:

| `charge_control_end_threshold` | UPower `charge-end-threshold` |
|---|---|
| 60 | 80% |
| 70 | 80% |
| 95 | 80% |

`ChargeThresholdEnabled` stays `false` throughout, which is consistent: UPower
has not enabled a threshold, something else has.

There is also no way to make UPower re-read it from outside. `Refresh()` is not
implemented on `org.freedesktop.UPower.Device`, and raising a synthetic udev
change event on the battery does not move the value either.

## Expected

The panel should report the limit the firmware is actually holding, and should
treat a limit as active whenever `charge_control_end_threshold` is below 100,
independent of the current charge level.

## Suggested fix

Read `charge_control_end_threshold` first and treat UPower as the fallback
rather than the other way round. If UPower is kept as the primary source, gate
it on `ChargeThresholdEnabled` being true, since its threshold properties are
meaningless when it is false.

For `Model.chargeThresholdActive()`, the state of charge is not evidence about
whether a cap exists. A cap is active when the threshold is below 100, and a
battery sitting at 99% under a 60% cap is exactly the case the current
heuristic gets wrong.

## System details

- Omarchy 4.0.2-1
- Kernel 7.1.9-arch1-2
- UPower 1.91.3 (client and daemon)
- ASUS Zenbook UX8402ZE, `asus_nb_wmi` loaded, single battery BAT0
- Intel Core i9-12900H, Intel Iris Xe and NVIDIA RTX 3050 Ti Mobile