Meter DC charging only, on a monotonic clock

The charging session meter used the head unit's wall clock, which jumps when it
picks up GPS or NTP time. One forward jump mid-charge invented both kWh and
hours. The consumption counters already integrate on elapsedRealtime for exactly
this reason; the session meter now does too, and keeps wall-clock values only as
the start and end stamps a reader needs to place a session on a timeline.

Intervals longer than five minutes are no longer bridged. A head unit that slept
mid-charge came back and billed the whole gap at the last power reading, and a
session interrupted overnight reported the night as charging time. Reported
duration is metered charging time now, not the span from start to end.

Sessions are metered on DC alone, at or above 10 kW. AC charging on this car is
an overnight affair the head unit sleeps through, so its curve, duration and
energy were guesses either way. The charging screen says so rather than letting
the previous DC session's figures be read as the current AC charge.

Also:

- A daily consumption record uploaded after an offline spell carries the
  lifetime total as it stood at the close of that day. Every backlogged day used
  to be stamped with the current lifetime, which plots as a flat line and one
  cliff.
- The offline session queue is capped at 50. It is a single SharedPreferences
  string read into memory in full, and nothing drained it while the cloud
  endpoint was unconfigured.
- A long charge keeps the start of its curve: at 720 points the sample interval
  doubles and the curve is thinned, rather than dropping the oldest point.
- The cloud sync throttle runs on the monotonic clock, and catch-up sends up to
  10 days and 10 sessions per cycle rather than one and three.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

app/src/main/java/com/evsuite/abrp/ConsumptionTracker.java

@@ -129,6 +129,10 @@ final class ConsumptionTracker {
         tripA.save(e, "a");
         tripB.save(e, "b");
         today.save(e, dayKey(todayDate));
+        // Lifetime as it stood at the end of this day, so a backlog uploaded days later
+        // does not stamp every one of those days with today's total — which would draw a
+        // flat line and then one cliff in anything plotting it.
+        lifetime.save(e, lifeKey(todayDate));
         e.commit();
     }
 
@@ -141,7 +145,15 @@ final class ConsumptionTracker {
 
     synchronized CloudSnapshot cloudSnapshot(LocalDate date) {
         rollDayIfNeeded();
-        return new CloudSnapshot(date.toString(), totalsForDay(date), lifetime.snapshot(), sohPercent());
+        return new CloudSnapshot(date.toString(), totalsForDay(date), lifetimeAtEndOf(date), sohPercent());
+    }
+
+    /** Lifetime as of the close of {@code date}, falling back to the live counter. */
+    private Totals lifetimeAtEndOf(LocalDate date) {
+        if (date.equals(todayDate)) return lifetime.snapshot();
+        Totals stored = loadTotals(lifeKey(date));
+        boolean missing = stored.km == 0 && stored.kwh == 0 && stored.hours == 0 && stored.soc == 0;
+        return missing ? lifetime.snapshot() : stored;
     }
 
     synchronized LocalDate nextStoredDayAfter(LocalDate lastUploaded) {
@@ -249,6 +261,9 @@ final class ConsumptionTracker {
 
     private static String dayKey(LocalDate date) { return "day_" + date; }
 
+    /** Deliberately shares the {@code day_<date>} prefix so pruning reaches it too. */
+    private static String lifeKey(LocalDate date) { return "day_" + date + "_life"; }
+
     private Totals loadTotals(String key) {
         return new Totals(bits(key, "km"), bits(key, "kwh"), bits(key, "h"), bits(key, "soc"));
     }