## Summary

The battery widget / power panel shows **0W discharging** on a laptop whose ACPI embedded controller exposes a `power_now` sysfs attribute that exists but cannot actually be read. `omarchy-battery-status` trusts the attribute because `[[ -r ]]` passes, gets an empty string from the read, and awk coerces it to `0W` — discarding the correct value that UPower already computed.

## Expected behavior

The widget should show the real power draw (e.g. `16.8W`, `29.9W`), matching UPower's `energy-rate`.

## Actual behavior

`omarchy-battery-status --shell` reports `rate 0W` while discharging.

## Steps to reproduce

On affected hardware (here: HP Pavilion Gaming Laptop 15-dk0xxx, battery `BAT1`):

```bash
# The sysfs attribute exists and is world-readable, so [[ -r ]] passes...
ls -l /sys/class/power_supply/BAT1/power_now   # -r--r--r-- 1 root root ...

# ...but reading it fails:
head -c 20 /sys/class/power_supply/BAT1/power_now
# head: error reading '.../power_now': No such device

# Meanwhile UPower has the correct value:
upower -i /org/freedesktop/UPower/devices/battery_BAT1 | awk '/energy-rate/ { print $2 }'
# 29.9735

# And the widget script zeroes it out:
omarchy-battery-status --shell
# percentage  40%
# state       discharging
# rate        0W        <-- should be ~16-30W
```

## Root cause

`bin/omarchy-battery-status` lines ~50-57:

```bash
if [[ -r $battery_path/power_now ]]; then
  power_rate_raw=$(awk -v microwatts="$(<"$battery_path/power_now")" 'BEGIN { print microwatts / 1000000 }')
```

`[[ -r ]]` only checks that the file exists with read permission, not that the read succeeds. On this HP/ACPI firmware the read() syscall returns `ENODEV` ("No such device"), so `$(<...)` captures an empty string, `awk` computes `"" / 1000000 = 0`, and the correct UPower `energy-rate` value is overwritten. The same latent issue affects the `current_now`/`voltage_now` fallback.

The fix is to only trust the sysfs value when the read returns a non-empty numeric string, falling back to UPower's `energy-rate` otherwise.

## Notes

- PR #6845 ("Fix battery status on multi-battery machines") rewrites this exact block and, as part of its metering logic, already discards invalid/empty `power_now` reads (`[[ $microwatts =~ ^-?[0-9]+$ ]] || continue`) — which fixes this bug as a side effect. It would be good to add a regression test there for the ENODEV-on-read case (attribute present but read fails).
- A local user-side workaround is to clone the power plugin and guard the sysfs read; happy to share.

## System details

- Omarchy: 4.0.0-1 (package `omarchy`)
- Kernel: 7.1.8-arch1-3 (x86_64)
- Machine: HP Pavilion Gaming Laptop 15-dk0xxx (Mobo 85FA, BIOS Insyde F.67)
- Battery: Hewlett-Packard PABAS0241231, BAT1, Li-ion
- Desktop: Hyprland 0.56.2 (Wayland), SDDM
- CPU: Intel Core i5-9300H; GPU: Intel UHD 630 + NVIDIA GTX 1050 Max-Q
- Full diagnostics in `/tmp/omarchy-debug.log`; screenshots of the 0W panel are available and can be attached on request.