biometrics: RecordedTime is date-only, so prime's own sort_by | last recipe can't pick the latest same-day reading

[DTTerastar]

Problem

RecordedTime for biometrics is date-only, normalized to local midnight — internal/cronoapi/export.go:155-160 (parseRecordedTime), and cmd/prime.go says so outright: Cronometer's CSV exports don't carry meal-time, so all times sort as 00:00.

That makes the recipe prime itself advertises unable to do what it claims:

crono-export biometrics --since 30d --format json |
  jq 'map(select(.Metric == "Weight")) | sort_by(.RecordedTime) | last'

With two weigh-ins on the same day, every RecordedTime ties at 00:00. sort_by is stable, so last returns whichever row happened to come out of the CSV last — not the latest measurement, and not reliably the same one across runs if upstream ordering shifts.

Why this is worth fixing rather than ignoring

This is the same user-visible failure as liftoff-export-cli#30 ("give me the day's weight") arriving by a different route. There it was duplicate rows; here it's unorderable ties in the documented recipe. Two weigh-ins on one day is common for anyone tracking weight seriously.

Note the fix is not dedupe — multiple biometric readings per day are legitimate data and collapsing them would destroy signal. servings, exercises, and biometrics are all event logs where multiple rows per day are the point.

Options

1. Stable tiebreak — carry the source CSV row index as a field so sort_by([.RecordedTime, .seq]) is deterministic. Doesn't invent precision that isn't there, but does make "last" mean something.
2. Fix prime's recipe and say why — document that same-day biometrics have no intra-day ordering, and point at whatever tiebreak exists. Cheapest honest option.
3. Check whether Cronometer's API exposes a real timestamp the CSV export drops. If it does, option 1 becomes unnecessary.

I'd start with 3, since it decides between the other two.