Let a meal say what kind of food it was

Grams alone put dry and fresh in the same total, so the log could not show that
fresh had been creeping up or that a soft stomach followed a switch. A meal can
now carry a kind the user names themselves.

The whole thing is optional, and that constraint shaped most of it. "No kind"
is a real value rather than a missing one: it is what every meal already logged
carries, so nothing needed migrating; it is always offered in the picker; and
with no kinds defined the picker, the legend and the split are all absent, so
the app is byte-for-byte the one it was for anyone who never wants this. The
checks cover that case specifically, because it is the one nobody would notice
breaking.

Kinds are a third synced collection beside events and exercises, with the same
contract — uuid ids, per-item last-write-wins, tombstoned deletes — so renaming
a kind updates the meals logged as it, and deleting one leaves them readable
under the name the tombstone kept. FoodKindStore duplicates ExerciseStore
closely; Store and ExerciseStore were already near-twins, so a third in that
shape is this file's pattern and leaves two working collections untouched.
Folding all three into one store over a table name is the tidier end state and
a separate job.

Two decisions worth naming. The default kind is a flag on the kind rather than
a profile field: the profile is last-write-wins across the whole row, and this
codebase already carries a special case for pedigree_id because that dropped a
value once — per-item LWW means two devices that each choose a default resolve
to the newer instead. And each kind keeps a colorIndex fixed at creation, so
deleting one never repaints the charts of the kinds around it.

The bars stack by kind with a line fitted per kind. Each line sits at that
kind's own daily amount rather than at the top of its segment: the segment's
height is what the kind ate, but its position is an accident of what is stacked
beneath it. So a line can cross a segment it does not belong to — dashed and in
the kind's colour, with the figures named underneath either way.

One sentence per kind would grow with the list, so only kinds whose move beats
their own scatter get one and the rest fold into a clause. Both tests are ones
foodTrend already applied; nothing new is being claimed.

A guest labels a meal with a kind that exists but cannot add, rename or delete
one, exactly as with the exercise library.

README.md

@@ -26,6 +26,16 @@ source-of-truth and sync between devices.
   tombstones) via `POST /api/exercises/sync`. Training sessions are ordinary
   events (`type: "training"`) referencing an exercise by id, so they ride the
   event sync unchanged.
+- Food kinds (`Dry`, `Fresh`) are a third synced collection with the same
+  contract, via `POST /api/foodkinds/sync`; a meal references one by
+  `foodKindId`. Empty means **no kind**, which is what every meal logged before
+  kinds existed carries — so nothing needed migrating and nobody is made to
+  classify their food. Which kind a new meal starts on is a flag on the kind
+  itself rather than a profile field: the profile is last-write-wins across the
+  whole row (see the `pedigree_id` special case below), and per-item LWW lets
+  two devices that each chose a default resolve to the newer instead of
+  fighting. Each kind also keeps a fixed `colorIndex`, so deleting one never
+  repaints the charts of the ones around it.
 - The puppy's name and birthday are a per-account profile stored on the host
   (`GET`/`PUT /api/config`), so a new device picks them up automatically instead
   of being configured per-client. The client caches the last-seen values in