set/apply/TUI: skip pseudo-batteries without charge control attributes

[lucserre]

hidpp_battery_N and similar power_supply nodes report type=Battery but
expose no charge_control_* files. ListBatteries() returns them, so
set/apply/TUI attempted SysfsWriteInt on non-existent paths and aborted
before/after writing the real battery (ENOENT), breaking persistence.

Backends now return ErrNotChargeable from SetThresholds when the target
battery lacks the attributes they would write (per-battery check instead
of globally-derived capabilities), and the three call sites skip such
batteries instead of failing. Fixed-path backends (Apple, Acer, Samsung,
Sony, Huawei, Lenovo-ideapad, LG legacy) are unaffected.

[jash8506]

I hit this with a Logitech keyboard (hidpp_battery_0) and opened #14/#15 before finding your PR — both now closed as duplicates, sorry for the noise.

Two things I ran into that this doesn't cover, which I've stacked on your branch as lucserre#1 rather than proposing separately:

1. Peripherals still enumerate. ErrNotChargeable is consulted on the write path, so detect and status still list the keyboard as a battery at 0% with unreadable thresholds. The kernel marks these via scope — hid-logitech-hidpp hardcodes POWER_SUPPLY_SCOPE_DEVICE — so filtering in ListBatteries keeps them out of every consumer. It complements SupportsChargeControl rather than replacing it: scope answers "is this a system battery", yours answers "can this battery do thresholds", and the latter still matters for a system battery with no charge_control_*.

2. The error blames permissions. SysfsWriteString uses os.WriteFile, which passes O_CREATE; sysfs refuses to create files and returns EACCES, so a missing attribute reads as permission denied even under sudo. That's why I spent a while thinking sudo was the problem. The read path returns no such file or directory for the same path in the same run.

Entirely your call whether either is wanted — happy for you to squash, cherry-pick, or ignore.