Fix period logging fragmentation, add merge action to History

[mapgie]

Summary

Root cause: PeriodRepository.periodForDate — the only check that decides whether a "log period" tap should edit an existing period or create a new one — had two gaps:

• An ongoing period (endDate == null) was treated as extending only through LocalDate.now(). Reopen the app on a later day (or check a future date) and the same ongoing period silently stopped matching, so the next tap created a brand-new, disconnected period instead of continuing it.
• A period with an explicit end date had no adjacency handling at all. Logging the day right after a closed period (e.g. because the previous day was saved with an explicit end date instead of left "ongoing") fell outside its range entirely and created a new period rather than continuing it. This is exactly how logging June 28 → 29 → 30 fragmented into a 1-day period on the 28th and a separate ongoing period on the 30th, with no way to log or reclaim the 29th.

There was also no way to recover from fragmentation once it happened — History only supports delete, not merge.

Changes

• PeriodRepository.periodForDate: ongoing periods now match any future date (no upper bound); a period also matches the day immediately after its explicit end date, so consecutive-day logging continues the period instead of splitting it.
• LogPeriodViewModel: when opened for a date that continues an adjacent period (rather than a date already inside its range), the end date is auto-extended to that date so a single Save commits the continuation.
• PeriodRepository.mergePeriods (new): merges two period entries into one, combining notes and symptoms, keeping the earlier entry and deleting the later.
• HistoryViewModel.mergePeriods (new): wraps the repository merge and cleans up the absorbed period's tracking-log entries (flow/symptoms), mirroring the existing delete cleanup.
• HistoryScreen: each period card now has an overflow menu offering "Merge with <date> period" for its chronological neighbours, with a confirmation dialog before merging.
• Data migration: PeriodRepository.mergeAdjacentPeriods(), a one-time backfill (same pattern as the existing overlap-merge migration, gated by a new periodAdjacencyMergeDone preference flag) that automatically rejoins periods already fragmented by this bug — any two periods sitting exactly one day apart get merged and the absorbed period's tracking logs cleaned up. Sequenced to run after the existing overlap-merge migration, since resolving an overlap can make a period newly adjacent to a third one. Users who already hit this bug won't need to manually fix their data.
• Added regression tests for periodForDate covering the ongoing/future-date case and the end-date adjacency case.
• Added LESSONS.md entry and changelog fragment.

Test plan

• Log a period for day 1, save with an explicit end date (not "ongoing"), then log the very next day — confirm it opens the same period for edit (extended), not a new one.
• Log an ongoing period, background/reopen the app on a later simulated date, tap a day within the new "today" — confirm it still edits the same ongoing period.
• In History, use the overflow menu on two periods with a gap between them and confirm "Merge with…" combines them into one continuous entry, keeping notes/symptoms from both.
• Seed the DB with two periods one day apart, reinstall/reopen the app, and confirm the migration auto-merges them into one on first launch.
• Run python3 a11y_check.py (already passing locally).

https://claude.ai/code/session_01QezQYsNLctrCF2mST3Z2Lf