intraday: samples at 24h chunk boundaries can be emitted twice (no dedupe) #41

Problem

intraday walks the requested range in 24h chunks where each chunkStart equals the previous chunkEnd (cmd/intraday.go:92-95), and passes both startdate and enddate to the Withings API (cmd/intraday.go:100-101). Samples from every chunk are appended into one flat slice (cmd/intraday.go:108,114) with no dedupe by timestamp.

If Withings treats enddate as inclusive, any sample landing exactly on a chunk boundary is returned by both the chunk that ends there and the chunk that starts there, and appears twice in the output.

Because --since/--until snap to local midnight, boundaries are exact :00:00 — precisely where a minute-granularity sample is likely to sit.

Confidence

• That the code path has no dedupe: certain, read it directly.
• That it fires in practice: medium. It depends on whether Withings' enddate is inclusive, which I could not verify without a live token. Worth a quick check against a real account before investing in a fix — request a 2-day range that spans a midnight with known intraday data and look for a repeated timestamp.

Fix

Either advance chunkStart by intradayWindow + 1s so the windows don't overlap, or key the accumulator on timestamp. The second is more robust if Withings' inclusivity ever changes.

Cheap regression check: a table test over two adjacent synthetic chunks that share a boundary sample, asserting the timestamp appears once.