Add a Meals log to Habits, with a bulk label for unlabelled meals

A meal's amount and its kind are both optional by design, which is what
makes them easy to lose track of: a meal with no kind sits in the grey
band on the food chart, one with no grams is dropped from it silently,
and there was nowhere to go and see which meals those were.

The panel lists every meal across every day, ignoring the day picker as
the Notes log does — the ones worth finding are spread through history
rather than sitting on the day being viewed. Each filter chip carries
its own count, so the size of the gap reads off the panel without
selecting anything. Rows go through attachRowHandlers, so tapping one
opens the usual edit dialog and long-press still measures.

On the "no kind" filter it also offers to label the whole list at once,
which is what history needs after kinds arrived months into logging.
backfillFoodKind does it in one pass — one save, one sync, one render,
following setDefaultFoodKind rather than calling updateEvent hundreds of
times; sync already posts the whole event list, so it costs nothing
extra on the wire. The optional cut-off date filters the list as well as
the edit, so the number on the button is the rows on screen: labelling
all of history as one kind is wrong if the food was switched partway,
and once labelled the early meals cannot be told apart. There is no
undo, so the guards are the live count, the number on the button and a
confirm. Owner-only; the server's guest rules would refuse it anyway.

Meals are the only event type that gets this — the only one with
optional fields worth filling in afterwards.

Nothing appears until there is a meal to list, and the kind filter and
bulk block wait for a kind to exist, so an account not using kinds is
unchanged.

README.md

@@ -92,6 +92,32 @@ of them, because logging has to be one tap from wherever you are.
   setting — but being module-level is what carries them through the re-render a
   background sync causes every minute. Long-press has no keyboard equivalent, so
   this is touch and mouse only.
+- **The Meals log** in Habits lists every meal across every day, beside the
+  Food (grams) chart, ignoring the day picker as the Notes log does — the meals
+  worth finding here are spread through history, not on the day you happen to
+  be viewing. It exists because a meal's two extras, its amount and its kind,
+  are both optional by design, which is exactly what makes them easy to lose: an
+  unlabelled meal sits in a grey band on the chart, one with no grams is dropped
+  from it silently, and neither was findable. Each filter chip carries its own
+  count, so the size of the gap reads off the panel without selecting anything.
+  Rows go through `attachRowHandlers` like every other log, so tapping one opens
+  the same edit dialog and long-press still measures. The list is capped at
+  `MEALS_LOG_PAGE` with a *Show more* — a year of logging is a thousand rows,
+  and `render()` draws every panel on every pass. Meals are the only type that
+  gets this: they are the only events with optional fields worth filling in
+  afterwards, a pee being a pee and a weigh-in being refused without a number.
+- **Labelling old meals in bulk.** Kinds arrived after months of logging, so
+  everything recorded before them has none. `backfillFoodKind` sets one kind on
+  every meal the current filter lists in a single pass — one save, one sync, one
+  render, following `setDefaultFoodKind` rather than calling `updateEvent`
+  hundreds of times. It costs nothing extra on the wire either, since sync
+  already posts the whole event list. The optional *Only before* date is the
+  part that matters: labelling all of history as one kind is wrong if the food
+  was switched partway, and once labelled the early meals cannot be told apart
+  from correctly labelled ones. The cut-off filters the list as well as the
+  edit, so the number on the button is the rows on screen. There is no undo —
+  the guards are the live count, the number on the button, and a confirm.
+  Owner-only, and the server's guest rules would refuse it anyway.
 - Each tab is a `.tab-panel` wrapper around the existing sections. The
   **wrapper** is what gets hidden, never the sections: `walk-timeline` and
   `walk-trend` carry their own `hidden`, set by `renderWalkPatterns` once a walk