Stop a marked day distorting Timing, the trends, and its neighbour

Marking a day "not counted" was implemented by filtering its events out of the
list the cross-day panels are given. That is too blunt a tool, because three of
those panels are not asking "which days count":

  - Timing's marker is how long since the last pee, which is a question about
    now. With the marked day's events gone it answered from the day before —
    27 hours instead of 2 in the case I reproduced, so the marker sat off the
    end of its band.

  - The sleep and walk trends draw the day you are looking at against yesterday
    and the average. Marking that day collapsed its own curve to a flat zero.
    Marking a day means don't let it drag the average, not pretend nothing
    happened on it.

  - A nap from 23:00 on a marked day to 07:00 the next morning lost its
    sleep-start, leaving a dangling sleep-end that pairWindows discards. The
    next day — not marked — lost seven hours it really slept. Nobody reported
    this one; it turned up while reproducing the other two.

None of them needed the filtering, because each already excludes marked days
itself and more precisely than deleting events can: gapsBetween throws away a
gap that *touches* one, the trend loops skip them when averaging, weeklyData
and the actograms zero and hatch them. The filter was a second mechanism
fighting the first. Only the by-hour and training panels still get the filtered
list — they bucket individual events and care about neither day boundaries nor
spans, which is exactly what removing events does.

README.md

@@ -164,6 +164,15 @@ heading, takes the day you're looking at out of the aggregates.
 - **What stops counting** is the behaviour: sleep hours, timeline and trend,
   walk minutes and patterns, pee/poo/meal counts, food, by-hour, the training
   grid, and the Timing panel's typical gaps.
+- **Marking a day is not the same as deleting its events**, and only two panels
+  are handed a filtered list (by-hour and training, which bucket individual
+  events and care about neither day boundaries nor spans). The rest take the
+  whole log and exclude days themselves, because three things break if the
+  events simply go: "how long since the last pee" is a question about *now* and
+  answered from the wrong event; the trend curve for the day you are *looking
+  at* collapses to zero; and a nap from 23:00 on a marked day to 07:00 on the
+  next loses its `sleep-start`, leaving a dangling `sleep-end` and costing the
+  next day — which isn't marked — seven hours it really slept.
 - **What keeps counting** is weight and notes. A weigh-in and a vet note are
   records of fact, not behaviour a sparse logger distorts, so they stay on the
   weight curve and in the Notes log.