Rewrite battery-remaining estimate around per-wake drop rate

The old estimate used a single linear percent/second rate from the
current discharge cycle's battery_history, which resets to empty on
every recharge -- so "not enough data yet" kept showing up despite the
frame having plenty of history overall, and the rate it did compute was
tied to whatever refresh interval produced it (changing the interval
didn't move the estimate until enough new history accumulated under
the new setting).

Now pulls the last 100 rows from the permanent battery_log table
instead, and averages the *per-wake* percent drop (not per-second) --
recharge jumps are skipped rather than counted as negative drain,
flat/zero-drop wakes still count so the rate isn't overstated, and
more recent steps are weighted more heavily. The per-wake rate then
converts to wall-clock time using the frame's current
refresh_interval_s and quiet-hours settings, so halving the refresh
interval roughly halves the estimate immediately, and quiet hours
correctly stretches it out (fewer wakes/day at the same per-wake cost).

server/app/quiet_hours.py

@@ -114,6 +114,18 @@ def in_quiet_hours(cfg) -> bool:
     return in_quiet
 
 
+def quiet_span_s(cfg) -> int:
+    """Seconds per day quiet hours keeps the device asleep -- 0 when
+    disabled. Used by common.py's battery-remaining estimate to turn a
+    per-wake battery cost into a wall-clock duration: quiet hours cuts
+    how many wakes happen per day without changing what any one wake
+    costs, so it belongs in the wakes-per-day math, not the per-wake
+    rate itself."""
+    if not cfg.quiet_hours_enabled:
+        return 0
+    return _quiet_hours_span_s(cfg.quiet_hours_start, cfg.quiet_hours_end)
+
+
 def max_expected_gap_s(cfg) -> int:
     """Longest gap between wakes the device might legitimately have --
     normally just refresh_interval_s, but quiet hours can make the real