feat(types): add create/delete for nutrition-log and hydration-log

[saiteja007-mv]

Fixes #6.

nutrition-log and hydration-log accept dataPoints create and dataPoints:batchDelete, but the registry marked them read-only, so ghealth data nutrition-log create did not exist.

Verified against the live v4 API

Run on my own account; every data point created during testing was deleted and confirmed gone with a 404 read-back.

type	create	update (PATCH)	delete
nutrition-log	200	500 INTERNAL	200
hydration-log	200	500 INTERNAL	200
weight (control, already writable)	200	200	200

End-to-end with the built binary after the change:

$ ghealth data nutrition-log create --json '{"nutritionLog":{ ... }}'
$ ghealth data hydration-log create --json '{"hydrationLog":{ ... }}'
$ ghealth data nutrition-log delete --ids <id>
$ ghealth data nutrition-log get --id <id>     # 404, as expected

Why update is deliberately omitted

PATCH on either type returns 500 INTERNAL — with a field mask and without one — and the stored value is unchanged afterwards. Exposing an update subcommand here would ship a command that can only fail, so both types are create/delete-only. Editing means delete + create. There is a test pinning this, so a later "make the writable types consistent" pass doesn't quietly add it back.

The food catalog stays read-only, also pinned by a test: a custom food is an anonymous nutrition-log entry with inline nutrients, not a new catalog entry. Marking the nutrition types writable invites the opposite assumption.

Two API behaviours worth knowing when writing these

Both confirmed the same way, and they cost me real debugging time:

1. The interval must be non-empty. startTime == endTime is rejected with 400 INVALID_TIME_RANGE. A one-shot "log this now" needs a synthesised end (e.g. +60s).
2. Omitting startUtcOffset/endUtcOffset is accepted, and silently wrong. They are documented as required, but a write without them succeeds and files the entry at UTC wall-clock time rather than the user's — a 12:55 −05:00 entry lands at 12:55Z, five hours out. Since create passes --json through untouched, anyone modelling a payload by hand will hit this. Happy to send a follow-up PR adding a pre-flight warning for it if that's wanted.

Example payload for the docs, if useful:

ghealth data nutrition-log create --json '{"nutritionLog":{
  "interval":{"startTime":"2026-09-03T19:00:00Z","startUtcOffset":"-18000s",
              "endTime":"2026-09-03T19:01:00Z","endUtcOffset":"-18000s"},
  "foodDisplayName":"Oats","mealType":"BREAKFAST","serving":{"amount":1},
  "energy":{"kcal":300},"totalCarbohydrate":{"grams":50},"totalFat":{"grams":5}}}'

go test ./... and go vet ./... pass. CLA signed.