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.

src/app.js

@@ -2792,12 +2792,28 @@
     // logger distorts, so they count everywhere regardless.
     renderWeight(events);
     renderNotes(events);
-    // Everything that aggregates across days works from the counted list.
-    renderTiming(counted);
-    renderWeekly(counted);
-    renderSleepTimeline(counted);
-    renderWalkPatterns(counted);
-    renderSleepTrend(counted);
+    // These take the whole list even though they aggregate, because each
+    // already knows about marked days and does something more precise with
+    // them than dropping their events would:
+    //
+    //   - gapsBetween throws away a gap that *touches* a marked day, and
+    //     "how long since the last one" is a question about now, not about
+    //     the window — with the events gone it answered from the wrong one.
+    //   - the trend curves skip marked days when averaging, but the curve for
+    //     the day you are looking at is about that day; marking it means
+    //     "don't let it drag the average", not "pretend nothing happened".
+    //   - weeklyData and the actograms zero and hatch a marked day themselves,
+    //     and need the events either side of it: a nap from 23:00 on a marked
+    //     day to 07:00 on the next belongs, for those seven hours, to the next
+    //     day — which is not marked and should show them. Dropping the
+    //     sleep-start left a dangling sleep-end and lost the window entirely.
+    renderTiming(events);
+    renderWeekly(events);
+    renderSleepTimeline(events);
+    renderWalkPatterns(events);
+    renderSleepTrend(events);
+    // These two bucket individual events with no notion of a day boundary or a
+    // span, so removing the marked days' events is exactly the right tool.
     renderHourHeatmap(counted);
     renderTraining(counted);
   }