FullCharge: Stop the carried-basis KDoc from claiming a closed retirement set

The lifetime sentence listed the out-of-band check, reset, and trigger
consumption as the only ways a carried arming basis is retired. Reconnect
window expiry, a replug that re-derives to nothing, and the any-level
revocation retire it too, so the list was not exhaustive. Describe the
retirement paths without asserting closure, keeping the load-bearing
point: the basis carries no timestamp, so a retry is deliberately not
bounded by the original reconnect window.

Fixes review finding F5.

Author: d4rken

app/src/main/java/eu/darken/amply/fullcharge/core/QuickFullChargeGesture.kt

@@ -23,9 +23,11 @@ enum class PolicyEvidence { PROTECTIVE, UNRESTRICTED, UNKNOWN }
  * reading alone can never reconstruct a limit hold, and every retry after a missed window used to be
  * inert. A rejected sub-[minReconnectMillis] gap is deliberately treated as a *non-event*: the basis
  * returns to the ordinary plugged-period latch and from there persists exactly as long as a freshly
- * observed hold would — it carries no timestamp and is retired only by the out-of-band check below,
- * by [reset], or by consuming a trigger. So a retry is not bounded by the original window; that is
- * the point (see `a retry long after the original unplug still triggers`).
+ * observed hold would. Carrying no timestamp of its own, it is subject to the same retirement paths
+ * as any latched basis — the out-of-band check below, an any-level revocation, expiry of a reconnect
+ * window it later opens, a replug that re-derives to nothing, [reset], or consuming a trigger. What
+ * it is *not* bound by is the original reconnect window; that is the point (see `a retry long after
+ * the original unplug still triggers`).
  *
  * Two arming bases exist:
  * - Limit hold (default): Android's charging-policy hardware state reports the Pixel policy actively