Add a charging gauge: battery level on the eight LEDs when the charger goes in

[Joerikros]

What this adds

A charging gauge: when the charger goes in, and again when the battery reaches 100%, the
eight LEDs fill up to the battery level, with the last LED dimmed to its share (73% = five
full LEDs and a sixth at 84%). It lives as a single rule card on the Apps tab, below the
privacy rules, with its own full-screen editor.

Look

• Colour by level (red at empty → amber halfway → green at full), one colour, or a colour per
  LED, plus eleven ready-made presets (Traffic light, Red → green, Fire, Sunset, Ocean,
  Aurora, Rainbow, Four colours, Ice, Mint, White).

Readability — the eight LEDs sit behind one diffuser, so a solid run blurs into one glow:

• LEDs come on one by one (default) or all at once; one-by-one counts up to the level, holds,
  goes dark briefly and counts again for as long as the gauge shows.
• Every second LED is dimmed (default 25%, adjustable, 0% = off), so lit LEDs read as
  separate dots.
• The last lit LED blinks three times once the level is reached, then holds.

Timing

• Show for 2–30 s (default 8 s), up to 1 minute behind the existing two-step warning;
  brightness; "only when the screen is off"; optional repeat every N minutes while the
  charger stays in (off by default). The rule itself is off by default.

How it is wired

• Pattern.BATTERY is a new renderer pattern (core/Renderer.java, mirrored in
  Preview.kt for the on-screen strip). It is marked internal and hidden from the Style
  carousel and the rule pickers, since it needs a level only the charging trigger supplies.
• ChargingRule (singleton, prefs key chargingRule) and ChargingEvents, a pure tracker
  that decides plug-in and full moments once per charging session — starting the app on the
  charger is not a plug-in, and a phone sitting at 100% does not re-fire.
• Store fires it as an ordinary finite alert (AlertSource.CHARGING, arm = false)
  from the existing power receiver, now also listening to ACTION_BATTERY_CHANGED. The
  one-minute cap, duty-cycle guard, sustained-brightness taper, quiet hours and Battery
  Saver all apply unchanged; Engine is not touched. The low-battery guard never blocks it,
  because on the charger the level is already reported as full.
• One deliberate exception: cancelAlert() leaves a charging alert alone when the screen
  comes on — the screen waking as the charger goes in is exactly when the gauge is read.
• PatternCarousel is generalised into ChipCarousel<T> (with an optional leading slot for
  the preset miniatures); the Style tab uses it unchanged.

Tests

131 unit tests pass (:app:testDebugUnitTest :app:build :app:lint all green). New:

• RendererBatteryTest — fill maths, partial LED, alternate dimming, the one-by-one
  timeline (count / hold / gap / restart), the tip blink, clamping.
• ChargingEventsTest — once-per-session plug-in and full, priming on start-up, unplug reset.
• ChargingRuleTest, ChargingPresetTest — prefs round trips, clamping of malformed values,
  alert JSON, preset matching.
• PrivacyRuleTest updated for the internal pattern flag.

Device verification

Pixel 11 Pro XL, Android 17 (API 37), Shizuku transport. Charger faked with
adb shell dumpsys battery unplug / set level N / set ac 1 / set status 5, reset
afterwards:

• plug-in at 73% → HiLightCore: alert … battery for 8000ms; full → second alert; sitting
  at 100% → no repeat; unplug and re-plug at 20% → third alert; session released after 8 s.
• LED colours read back with dumpsys lights during the gauge at 62% and 50%: the run
  counts up one LED at a time, every second LED at 25%, the boundary LED at its share
  (0xd2f500 = 96% at 62%), the tip blinking three times, then the gap and a fresh count.

One thing worth knowing for anyone testing renderer changes: reinstalling the APK does not
restart the Shizuku user service, which keeps running the old dex. Kill it
(pkill -f 'com.hilight.(core.AdbHelper|studio:hilight)') and reopen the app first.

Notes for review

• The Japanese strings are a first pass and have not been checked against
  docs/i18n/ja-glossary.md, nor do they carry the per-entry English source comments the
  JA files use. Happy to adjust, or for a native review.
• New strings are grouped under charging_* in strings_rules.xml; README and CHANGELOG
  have a short entry each.
• I'm glad to split this into smaller PRs (core gauge / presets / readability) if that is
  easier to review.