FullCharge: Cancel a session only on a real native settings change

[d4rken]

What changed

A temporary full-charge session could silently end mid-charge without restoring the protective policy: the battery then charged to 100% and protection stayed off until changed manually. Reported from the HyperOS 3 verification run in #48, where the session's cancel-on-native-change watcher fired on a settings notification that carried no actual value change. Sessions now end without restoring only when the charging setting really changed outside the app.

Technical Context

• Root cause: the session service cancelled without restore on any change notification for the adapter's setting URIs. Settings notifications are dispatched asynchronously, so the session's own override write can be delivered after the observer registers, and the HyperOS provider can notify without a value change — either ends the session with the protective policy never re-written (evidence chain in #48: dashboard idle at 96% while the key monitor shows no value change after the override write).
• NativeChangeGuard (pure, unit-tested) ignores a notification whose sync readback still decodes to the session's override policy; a different, unrecognized, or unreadable value cancels as before, and adapters without sync readback (Pixel) keep the blanket cancel.
• A Shizuku readback timeout is TimeoutCancellationException, a CancellationException subclass — it is caught as "unreadable → cancel" rather than rethrown, which would silently drop the notification and keep a session alive past a genuine native change.
• Accepted trade-off (documented in the KDoc): a native change that decodes to the same policy — re-selecting the identical value, or editing an auxiliary key the decoded policy ignores (Samsung threshold during a PauseAtFull override) — is indistinguishable from noise and keeps the session running.
• The qualification ledger records the rest of the [Device support] Xiaomi 24117RN76G — settings discovery #48 beta run: absent key decodes as Intelligent (shipped assumption now confirmed), app-context three-mode control over direct WSS confirmed, cap fixed at 80%. Session-lifecycle re-verification on the next beta is the remaining ask.