WHOOP import: key journal entries to the wake day, not the onset evening (#136)

[ryanbr]

Fixes #136.

The bug

Imported WHOOP journal entries all read as "Without" in Insights — new (native) entries correlate, old (imported) ones don't. Not because they're unparsed (they are), but because they land on the wrong day.

WHOOP's journal_entries.csv keys each entry only by cycle_start — the onset evening — while parseCycles/parseSleeps and the native in-app journal all key by the wake day. So every imported entry sat one day early and never matched the recovery/sleep outcome it belongs to; Insights walks each outcome (wake) day, finds no matching "yes" entry, and buckets it into "Without." The old code even flagged this as "a minor correlation-only offset" — it isn't minor; it zeroes out the entire imported journal.

The fix

Build a cycle_start → wake-day map from the cycles CSV (reusing the existing wake-day rule: wake_onset ?: cycle_end ?: start) and key each journal entry to its cycle's wake day — the same day the outcome and native journal use. Falls back to the onset day only when the cycle isn't in the export. Both platforms (WhoopCsvImporter.kt + WhoopImporter.swift, via the shared WhoopDayKeying).

Non-destructive by design

No existing data is deleted. New/fresh imports are correct immediately. To correct already-imported history, a user removes + re-adds their WHOOP import — the existing, user-initiated flow that clears the imported device. We deliberately do not silently delete anyone's journal on import (an export that's ever shorter than a previous one would lose entries — not worth the risk).

Tests

Android: an entry with onset 2026-06-05 evening and wake 2026-06-06 keys to the 6th (not the 5th), with answeredYes intact; a second test pins the onset-day fallback when the cycle is absent. Full suite 2366 green. iOS keying mirrors the same logic through the shared, already-tested WhoopDayKeying.wakeDayKey (app-target keying isn't locally unit-testable — validated at release CI).

Out of scope

The secondary design question — whether a day with no journal entry should be "Without" vs. excluded (unknown) — is left for a separate discussion; this PR fixes the day-key misalignment only.

[ryanbr]

Update — the re-import duplication tradeoff is now fixed, safely.

The earlier version left a tradeoff: an existing user re-importing (without first removing the import) would keep the old onset-keyed rows and add the new wake-keyed ones → duplicates. Fixed now with a bounded range replace, not a wholesale delete:

• Before upserting, clear the imported device's journal across exactly the day span being re-written ([min, max] of the imported entries' days), then upsert.
• Bounded to the imported range, so journal outside it — e.g. older history from an earlier, wider export — is never touched. This is the "re-import replaces this period" semantics daily/sleep already have, and it can't lose data the way clearing the whole device would.
• Both platforms: new deleteJournalRange (deviceId + day-range scoped, mirrors the existing dailyMetric range delete) wired into the importer. Native (noop-journal) log is a separate device, untouched.

Residual (negligible): the very first night's onset row sits one day below the write range, so it's not cleared — one day, only for users who imported pre-fix and re-import without removing. Deliberately not reaching below the span we actually write.

Android 2366 unit tests green.