Analysis: read a rarely-read meter as coarse, not absent; newest rows first

Three things a reported Heizoel page got wrong at once. Its tank is dipped
a few times a year and its burner read every few months, which is exactly
the shape the coverage rules had not been walked through.

"No data" for data that exists. A tank books nothing until the next
dipstick closes the interval, so the stretch after the last dipstick is
covered by no run at all, and a bucket no run covers was reported missing.
The burner, whose run reaches into the window, said "only coarser data" --
the honest answer -- so one card claimed there was nothing while the
coverage panel beside it listed years of data. A bucket that no run covers,
no gap overlaps and no opening balance explains now reports the meter's
resolution when its preceding coverage is within one interval of its own
class: it is not silent, it is read rarely. A meter that does book its own
buckets and stops -- a dead hourly source, a sheet asked about a later
month -- still reads missing.

Auto answering twelve months with one bar. Coarse only means "longer than
a month", so a dipstick taken each autumn straddles a New Year as surely
as a month start: coarsening the chart to years bought nothing and cost
every point. The planning resolution now caps coarse at month when a run
crosses a local year edge, and a series that cannot resolve the natural
size no longer coarsens the whole chart -- it is drawn at that size with
its buckets marked, which the chart and table already explain.

A page contradicting itself. The comparison line above the ranking was fed
the leading measure's matched coverage but worded as if it spoke for the
page, directly above a burner row that did compare. It now names the figure
it is about.

Alongside: the "largest changes" ranking no longer drops a meter whose
change is not comparable. It ranks what can be ranked, then lists the rest
with their values and the reason -- the tank had been vanishing from its
own energy type. And every dated table now reads newest first, as lists
are read; charts stay chronological left to right, and the CSV export
stays ascending for spreadsheets.

A-41 to A-43 in the note record the three rules.

src/Core/Analysis/Time/BucketPlanner.cs

@@ -11,8 +11,10 @@ namespace MeterVault.Core.Analysis;
 /// A-06) — day up to 62 days, week up to 26 weeks, otherwise month — so "year to date" charts by month in
 /// February as in November, and one URL renders the same way all year. It never goes finer than the
 /// coarsest resolution any plotted series can resolve (<c>coarsestNeeded</c>): a monthly import asked by
-/// day would only produce "unresolved" buckets. It then coarsens until the buckets that actually exist — up
-/// to now — fit the caller's point limit, so centuries of history end up in years.
+/// day would only produce "unresolved" buckets. What a plotted run asks for is
+/// <see cref="Coverage.ResolutionClassifier.PlanningResolution"/>, which keeps data no bucket size can place
+/// from coarsening the whole chart (A-41). It then coarsens until the buckets that actually exist — up to now —
+/// fit the caller's point limit, so centuries of history end up in years.
 /// </para>
 /// <para>
 /// An explicit size is honoured, even finer than the data (those buckets read as unresolved, D-14), but