Stop a low charge voltage request from raising the charge voltage

[ainyan03]

What is wrong

Both setChargeVoltage implementations subtracted a bias from the argument before comparing it against their step table:

max_mV = (max_mV / 10) - 410;
if (max_mV > 436 - 410) { max_mV = 436 - 410; }

The argument is unsigned, so a request below the lowest step wraps around and is then clamped to the opposite end of the table. Asking for a gentler charge voltage produces a harsher one:

request	AXP192 (REG33H[6:5])	AXP2101 (REG64H)
3800 - 4090 mV	4.36 V	code 0 (reserved in current datasheet revisions)
4100 - 4500 mV	correct	correct
4600 mV and above	correct	code 0

A sketch that sets a lower ceiling for a small cell — M5.Power.setChargeVoltage(4000) — configures 4.36 V on the AXP192 instead.

The AXP2101 table also carried a 4.6 V entry. The current datasheet revisions document the constant-voltage register as 4.0 V through 4.4 V with code 0 reserved, so a request that reached that entry wrapped the index onto the reserved code as well.

What changed

Compare in millivolts against the real steps, take the highest step that does not exceed the request, and fall back to the lowest step when the request is under all of them. Every request inside the supported range keeps its previous result — only the two broken edges move.

Both headers now state the supported steps and what happens on either side of them, which nothing documented before.

Notes

• An early AXP2101 datasheet revision assigned code 0 to 4.6 V, while current revisions reserve it. No battery this library runs on charges to 4.6 V, so a request that high is held at the highest step every revision agrees on rather than sent to a code whose meaning depends on the silicon. The comment records this rather than asserting one revision.
• The parameter stays uint16_t, so a negative argument still converts to a large positive one and selects the highest step. That is unchanged by this PR and is better addressed where the setter contract itself is revised.
• setChargeCurrent has the same shape of problem (a request below the lowest step is raised to it, and on the AXP2101 the 25/50/75 mA steps are unreachable). Left out of this PR deliberately: it changes what setChargeCurrent(0) means, which deserves its own discussion.

Verified on hardware

Register read-back after each request, with the original value restored afterwards:

• Core2 (AXP192, chip id 0x03) — 3800 / 4000 / 4090 mV now select 4.10 V where they selected 4.36 V; 4100 / 4150 / 4200 / 4350 / 4360 / 4400 / 4600 / 5000 mV unchanged.
• Core2 v1.1 (AXP2101, chip id 0x4A) — 3800 - 4090 mV now select 4.00 V and 4600 mV and above select 4.40 V, where both wrote code 0; 4100 - 4400 mV unchanged.