fix: rearm rare-candy grants when a limit window resets

[Borisserz]

Summary

• Rare candy rearm previously required observing utilization < 100%. If the Mac slept or the app was quit through a 5h reset, the next poll could still be at 100% with a new resets_at, leaving candyGrantTier stuck at 1 (5 hours limit reached multiple times but no candy's are awarded to my bag #326).
• Keep stable window keys (claude.fiveHour, …) and persist candyWindowEpoch[key] from resets_at / Codex unix / Antigravity resetTime. A changed epoch clears the tier so a fresh 100% can grant again.
• First-time nil→epoch only records the epoch (no surprise grant on upgrade). Save-transfer merges epochs with the grant ledger.

Fixes #326

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation
• Other:

UI changes

Before	After
Hitting the Claude 5h limit multiple times could leave the bag empty if the app never saw a mid-window <100% sample	A new window epoch (resets_at) rearms candy even when utilization stays at 100% across the gap

Checklist

• swift build and swift test pass locally
• PR title and description are written in English
• UI changes are described above (before/after — images optional)
• No copyrighted assets, secrets, or private tooling references are committed (see CONTRIBUTING)
• Tests were added or updated for this change

Test plan

• swift test --filter 'RareCandy|CandyGrant|SaveTransferTests' (79/79)
• Injected “record epoch without rearm” → testRearmWhenWindowEpochAdvancesWhileStillAt100 RED; restored → GREEN
• After a 5h reset (or sleep through reset), hit 100% again with the app refreshing → bag gains 1× Rare Candy