nutrition/notes JSON values are all strings, inconsistent with servings/biometrics/exercises (typed numbers) #17

The CLI exposes five export subcommands. Three (servings, biometrics, exercises) return parsed records via gocronometer's typed parsers, so JSON numeric fields are JSON numbers. The other two (nutrition, notes) go through csvToJSON in internal/cronoclient/client.go which produces []map[string]string, so every value — including kcal counts, gram weights, and the Completed boolean — is a JSON string.

Demonstrated by prime itself, which calls this out as a "gotcha":

nutrition and notes JSON values are STRINGS (raw CSV) — cast with jq tonumber when doing math. servings, biometrics, exercises JSON values are already typed numbers.

Repro:

$ /tmp/crono-export nutrition --since 1d --format json | jq '.[0] | {kcal: .\"Energy (kcal)\" | type}'
{ \"kcal\": \"string\" }

$ /tmp/crono-export servings --since 1d --format json | jq '.[0] | {kcal: .EnergyKcal | type}'
{ \"kcal\": \"number\" }

The contract calls for consistent output shape across subcommands. An LLM agent or jq pipeline cannot rely on .kcal | tonumber everywhere or .kcal everywhere — it has to know which subcommand produced the row. That is exactly the kind of asymmetry the contract is supposed to eliminate.

Fix: parse the CSV columns to typed numbers / booleans inside csvToJSON (or a dedicated nutritionCSVToJSON), using the column header to pick a parser (kcal/g/mg/µg/IU -> float, Completed -> bool, Date -> stay string).

Severity: major