Give tips a date, a scope per child, and a dismissal that sticks

Three faults, all invisible while the tests passed. Advice was built for the
first child only, so a second child got none. The planned days feeding every
count were fetched once per parent and appended to one list, so a couple's
days were counted twice and every intensity and projection derived from them
was wrong. And dismissing a tip forgot the moment the page reloaded.

Tips now carry the date they concern, lifted from figures the rules already
computed, so a view of a month can show only what applies to it. They are
built per child and identified per child, so the same rule firing for two
children is two separate pieces of advice.

A dismissal is stored against a fingerprint of the facts that were dismissed.
When those facts change the advice returns with its new numbers, rather than
one click silencing a warning about a forfeiture that keeps growing.

frontend/src/types/entities.ts

@@ -216,6 +216,11 @@ export interface Tip {
   severity: 'info' | 'warning' | 'action'
   messageKey: string
   data: Record<string, unknown>
+  // Where this tip is anchored on a calendar: a single day, a span, or
+  // neither (many rules — e.g. balance_between_parents — have no date that
+  // makes sense to place on a calendar rail). Never both set at once.
+  anchorDate: string | null // ISO-8601 date
+  anchorRange: [string, string] | null // [ISO-8601 date, ISO-8601 date]
 }
 
 // Planning engine — POST /api/plan/propose (read-only preview, nothing is saved)