Charging: Warn when the hardware never confirms a fixed limit

[d4rken]

What changed

When a fixed charge limit is applied but the charging hardware never confirms it, the dashboard now shows an explicit warning ("the charging hardware hasn't confirmed the 80% limit yet — it may not be applying") instead of silently looking successful. Previously the "Applying…" spinner simply disappeared after 15 seconds whether or not the limit actually engaged — hiding exactly the failure class where the setting reads back fine while charging is never limited.

Technical Context

• Adapters declare when a confirmation is expected (confirmationExpected): Pixel only for a plugged fixed limit on a live, unmasked channel — state 4 spans the entire plugged fixed-limit session, while Adaptive idles at the ambiguous state 1 and Unrestricted maps to the same 1, so their absence proves nothing and they never warn. Sync-readback and plug-latched (GrapheneOS) adapters carry no expectation structurally; GrapheneOS's post-replug case staying silent is deliberate scope.
• The signal lives on ChargingState, not PendingRequest — mutating pending at expiry would infinite-loop the dashboard's settling-deadline observer. Deserving close review: computeUnconfirmedTarget + debounceUnconfirmed and their test matrices, and the clears in every apply publication path.
• Three false-positive classes are designed out: an authoritative readback of a different configured policy (native/competing change) obsoletes the request instead of warning; a 15s stability debounce damps the plug-in transient (an old request legitimately reads state 1 for the ~12s HAL transition); a second scheduled refresh at the 30s threshold makes the warning appear even when the failing HAL emits no broadcast.
• Residual limitations: on WSS-only Pixels a native change is indistinguishable from a failed old request (hidden settings unreadable — the journal wins and the warning may be wrong until any re-apply); whether wireless charging reports state 4 as reliably as wired is a pre-existing qualification gap; and a broken/thermal-masked status channel suppresses the warning rather than risking a false claim.
• Also folds the per-refresh hardware reads into one sticky battery readout shared by the decode, the pending computation, and the expectation check (plug state must never be joined across two sticky reads).