set/apply/TUI fail writing charge thresholds when a wireless mouse (hidpp_battery_N) is present

[lucserre]

Version: v2026.3.13 (AUR batctl-tui 2026.3.13-1)
OS: Arch Linux, kernel 7.1.9-arch1-2
Laptop: Intel Meteor Lake (Core Ultra 7 155U)

Reproduction:

1. Plug in a Logitech wireless mouse (HID++ receiver). hidpp_battery_3 appears under /sys/class/power_supply/ with type=Battery.
2. Run sudo batctl set --stop 80 (or apply, or press a in the TUI).

Actual:
The command fails and exits non-zero:
applying thresholds on hidpp_battery_3: writing "80" to /sys/class/power_supply/hidpp_battery_3/charge_control_end_threshold: open /sys/class/power_supply/hidpp_battery_3/charge_control_end_threshold: no such file or directory
(TUI shows: Error on hidpp_battery_3: ...)

Expected:
Only batteries exposing charge_control_* attributes are written; the mouse battery is skipped and the real battery (BAT0) is applied successfully.

Environment (ls -F /sys/class/power_supply):
BAT0/ → has charge_control_start_threshold, charge_control_end_threshold, charge_behaviour
hidpp_battery_3/ → capacity, status, type ... NO charge_control_* attributes
AC/, 2x ucsi-source-psy-*

Root cause (from code):

• ListBatteries() (internal/battery/sysfs.go) returns every power_supply whose type == "Battery", which includes hidpp_battery_N.
• set, apply, and the TUI apply loop over that full list and call backend.SetThresholds() for each.
• Backends (generic included) write charge_control_{start,end}_threshold without a per-battery existence check; the generic backend's capability flags are computed globally (any battery having the file makes the write enabled for all batteries), so the write aims at a sysfs file that does not exist on the mouse.

Impact:

• Any command (set/apply/TUI) fails outright whenever a HID++ peripheral battery is present, even though the real battery was already written.
• Persistence is broken in the same way: batctl.service (boot) and batctl-resume.service (resume) run batctl apply, so thresholds are not restored whenever such a device is connected.

Suggested fix direction:

• Filter to batteries that actually expose charge_control_* (per-battery capability check, e.g. skip hidpp_battery_N), rather than deriving capability globally and writing to every listed battery. set/apply/TUI: skip pseudo-batteries without charge control attributes #13 is attempt to fix.