feat(lte): time-on-band and time-on-cell statistics (v0.23.33-beta)

Closes #120.

The Tower and band changes panel listed every handover, newest first, growing
without bound. On a link that hands over several times a day it reads as a wall
of near-identical rows — it answers what happened, but not what the pattern is,
which is the question an operator actually has.

Dwell totals now sit above it: how long the modem has spent on each band and on
each cell, over 24 hours, 7 days or 30 days, ordered by time spent so the answer
is the first row rather than something to be worked out. Visit counts sit
alongside, because six brief stays and one long one are different situations
that share a total.

No new collection. History is already written on every change, so dwell is the
interval between consecutive events — the same reconstruction used for WiFi
roaming sessions.

Three decisions worth recording.

**The state in force when the window opened is included.** Without it, a link
that changed once yesterday would report a few minutes of dwell across seven
days, having silently dropped everything before the first change in range. The
last event *before* the window is fetched specifically to anchor that first
stretch.

**Aggregated carriers each count for the whole stretch.** A period on B1 and B3
together credits both with the full duration, so band shares describe how much of
the window each band was in use rather than dividing it between them. Totals can
exceed 100%, which is the honest description of carrier aggregation rather than a
rounding artefact.

**Absence is reported as absence.** A segment whose cell was never reported is
excluded rather than attributed to "unknown", a device with no history reads as
"no changes recorded" rather than an empty panel, and a window longer than our
records says so instead of implying the quiet period was real.

Logic lives in utils/lteDwell.ts with 17 tests. Verified end to end against
seeded history matching the reporter's own pattern: a 24-hour window covered
exactly 24 hours, B3 correctly showed 19 of them against a five-hour stretch
without it, cell totals summed to the window, and a 30-day request over 9 days of
records reported itself truncated.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/cellular.md

@@ -77,6 +77,26 @@ cell id means it handed over.
 This is deliberately not log-based. The modem this was built for may log nothing at all,
 so polling is the vantage point that always exists.
 
+## Where the link spends its time
+
+Handovers and band changes are also aggregated into dwell totals — how long the
+modem has spent on each band and on each cell — over 24 hours, 7 days or 30 days.
+
+Two properties are worth understanding:
+
+**Aggregated carriers each count for the whole stretch.** A period spent on B1
+and B3 together credits both with the full duration, so band shares describe how
+much of the window each band was *in use* rather than dividing the window between
+them. The totals can therefore exceed 100%, which is the honest description of
+carrier aggregation.
+
+**The window is bounded by when collection began.** History is written on change,
+so the panel says plainly when records start later than the range you asked for.
+
+The individual change events remain available underneath, folded away. They
+answer a narrower question — what happened, and when — and grow without bound,
+which is why they are no longer the primary view.
+
 ## Data-cap reset SMS
 
 Several European carriers sell "unlimited" data that is throttled past a daily allowance,