FullCharge: Switch charge modes from the gesture notification

[d4rken]

What changed

• While the reconnect gesture is enabled, its ongoing notification now offers two buttons to switch the charge mode directly: one sets the protective default (e.g. "Limit to 80%"), one sets "Always 100%".
• The buttons show in the notification's steady states only — the 10-second reconnect countdown stays a bare, time-critical instruction.
• If charging control isn't available when a button is tapped (e.g. Shizuku isn't running and no durable permission was granted), a notification now explains that the charge mode wasn't changed instead of failing silently.

Technical Context

• Both actions route through the existing serialized ACTION_SET_PERSISTENT_POLICY service command the widget's ∞80%/∞100% buttons already use (cancels a running session without restoring, force-writes so same-value writes still re-trigger the HAL, updates all surfaces). No new write path, no allowlist or capability-gate change.
• SessionNotifications.gesture() takes the protect policy as a required parameter fed from the adapter's declared defaultProtectivePolicy, so the action follows the capability surface instead of hardcoding the Pixel limit. Label handles FixedLimit/Adaptive with a generic fallback, mirroring the widget's protectButtonLabel.
• The two PendingIntents share an intent action and differ only in an extra, which doesn't factor into PendingIntent equality — hence distinct request codes (8/9).
• Actions are gated on an explicit IDLE || ARMED allowlist rather than != WAITING_FOR_RECONNECT, because TRIGGER also reaches the builder and must not offer a competing persistent write.
• The unwritable-control feedback lives in the refusal branch of the shared command: widget/tile pre-check writability and open the app instead, but a notification action fires a PendingIntent and cannot pre-check; the branch also covers a surface racing a lost write capability.
• Robolectric tests cover action count per gesture state (including TRIGGER), labels per policy, policy-to-extra wiring, foreground-service PendingIntent semantics/distinctness, and send() dispatch into the started-service record.