Battery: anchor SoC to AXP192 coulomb counter to stop the unplug-jump

[SnowWarri0r]

Problem

The reference firmware reports battery percentage from a single linear
formula on instantaneous voltage:

int pct = (vBat_mV - 3200) / 10;  // 3.20V → 0%, 4.20V → 100%

That formula has two well-known weaknesses on this hardware. Both produced
visible-and-confusing-to-the-user readings on my stick:

1. BLE/LCD load yanks the measured voltage 100–300 mV below the
   open-circuit value. The same physical SoC reads ~10–20 percentage
   points lower while busy than while idle, and the indicator wobbles in
   sync with whatever the stick is doing.

2. Charging polarization inflates the measured voltage by 50–100 mV.
   Pull USB and the reading drops 5–15 percentage points instantly,
   despite no actual charge having moved. From cc-buddy-bridge's daemon
   log:

   00:42  63%  (charging)
   00:43  64%
   00:44  64%      ← USB unplugged here
   00:46  55%      ← same SoC, different reading
   

Both surfaces — the BLE status ack consumed by desktop UIs and the
on-device DEVICE info page — share the same formula and the same wobble.

Fix

Switch the primary SoC signal from voltage-direct to the AXP192's
hardware coulomb counter (already exposed by the M5StickC Plus library
as M5.Axp.EnableCoulombcounter() / GetCoulombData()).

New battery namespace in src/battery.h:

• setup(): enable the coulomb counter.
• loop(): sample voltage at 1 Hz into a 60-slot ring buffer.
• First-time anchor: when the buffer fills, take its median (load is
  low at boot, so this is the cleanest OCV reading available) and look
  it up in a 12-point LiPo OCV-SOC table. Freeze that pct + the current
  coulomb value as the anchor.
• Steady state: SoC = anchor_pct + (coulomb_now - coulomb_anchor) / 120 mAh × 100, clamped to 0–100. The coulomb counter is unaffected
  by polarization or transient load — it counts actual charge in/out.
• Re-anchor: any time vBat ≥ 4.10 V and |I| < 30 mA, the cell
  is genuinely topped up. Re-anchor to 100% to correct any drift the
  coulomb counter accumulated over weeks of use.
• Light 8-sample median on top of derived pct catches single-tick
  AXP register glitches without flattening real charge motion.

xfer.h:status and the on-device DEVICE info page (main.cpp:_drawDevicePage)
both call battery::percent() — same SoC value visible from both
surfaces.

Cost

• RAM: +~600 bytes (60-slot float voltage ring + 8-slot int pct ring)
• Flash: +~1 KB
• CPU: ~5 µs per loop tick (1 Hz throttled)

Testing

I flashed this to my own M5StickC Plus and watched the same daemon log
column over the same time window:

Before (linear voltage formula):
   pct jumps 9–20 percentage points on USB plug/unplug events
   pct drifts 2–4 points from BLE bursts even with no real charge motion

After (coulomb counter anchored to OCV):
   pct stays stable across plug/unplug events (±0–1)
   pct moves at the actual charge rate (~+1%/min while charging at default current)
   re-anchor on full top-up keeps long-term drift bounded

Scope

Only battery.h (new), main.cpp (call battery::begin() and
battery::poll(), swap inline pct calc for battery::percent()), and
xfer.h (same swap). No protocol changes — the wire format is unchanged,
the bat.pct field just becomes meaningful.

CONTRIBUTING.md fit

Per CONTRIBUTING.md "What we will take": fixes for bugs that make the
reference not work as a reference. A battery indicator that swings 9 %
on USB unplug isn't a working reference of how this should look.