BatteryControl 1.0.2

Compatibility, reliability, and hardware-validation release after the platform
expansion in 1.0.1. No new features on purpose.

Reliability fixes found on real hardware

No more false "verification failed" alarms. When the firmware pauses an
active charge, the charge current tapers over up to ~2 minutes before macOS
reports the change. The old 60-second observation window gave up early,
reported the limit as unverified, and then silently recovered a few minutes
later. The observation window is now long enough for the measured hardware
behavior (still bounded; a real failure is still reported as a failure, and
a failed write still deactivates the limit). Verified on hardware: the
transition that used to false-alarm now confirms without one.
CLI force-charge. The GUI could charge past the limit; the CLI could not.
batterycontrol charge start [pct] and charge stop now exist, same path
and same safety gates as the GUI.
App survives in-place upgrades. If BatteryControl was updated while it
was running, the daemon (correctly) refused the old process's connections
forever, and the app silently retried. The daemon now logs why a client was
refused, and the app shows a "was updated while running" banner with a
one-click Reopen button. The accept/reject security decision is unchanged.

On the author's MacBook Air (Mac15,13, Apple M3, macOS 15.8, mBoot-20457.1.29
— the one verified profile):

Charge limits 60/50, 70/60, 80/70, 90/98, and 100/98 programmed, read back,
and confirmed against actual battery behavior — including limits below
Apple's native 80% floor.
Force-charge climbed 81% → 84% past an active 80% limit, then charge stop
re-engaged the limit at 84%.
The limit held through sleep and wake on AC and on battery; the daemon kept
its state, and no write storm followed the wake.
Daemon restart recovery confirmed on the shipping binaries (policy restored
from the persisted store, limit active and verified).

Platform scope: Apple Silicon M1–M5, macOS 14/15/26/27. Scope is wider
than the validated hardware; runtime capability probing decides what a
given machine can do, and unknown firmware stays read-only by design.
Verified: the M3 / macOS 15.8 / mBoot-20457.1.29 configuration above.
Compatible by capability: machines whose SMC keys probe cleanly. Not
physically validated by the project.
244 unit tests — up from 225 — including new coverage for the
verification window, the CLI charge commands, the rejection classifier, and
corrupt/interrupted policy-store recovery. Tests are not the same thing as
physical validation, and the compatibility tiers keep that distinction.

Only one hardware configuration is physically verified. Reports from other
M1–M5 Macs (via the compatibility report workflow in CONTRIBUTING) are how
the verified list grows.
Binaries are signed with an Apple Development identity, not notarized.
Gatekeeper asks for approval on first install; SHA256SUMS is attached.
batterycontrol --test-inhibit intentionally probes the legacy key family
and will honestly report failure on modern firmware — that is what it is
for.

Full changelog: compare with 1.0.1 — c885196...c99b8f8.