v0.5.7
Harden calendar state consistency and reduce background work
Calendar state could drift when a refresh completed after a save, a background write replaced a whole record, or a provider/projection update failed partway through. This change preserves confirmed client state, publishes complete event collections, and makes background recovery explicit. It also removes redundant reads and event rewrites without changing sync frequency for users. Client state and recovery
•Hydrate feeds, local calendars, share links, and proposals from the authoritative bootstrap response. Request epochs protect each resource from late responses and mutations; snapshot versions stop a delayed bootstrap from undoing a newer edit. Bootstrap readiness, connection refreshes, and Google settings have separate guards. Invalidated reads still finish their loading indicators.
•Serialize Google settings saves, apply the API's actual `googleState` response, and build partial updates from the latest confirmed state. Account changes remount the authenticated dashboard and prevent queued settings writes from crossing accounts. Inconclusive OAuth checks preserve the known connection and surface a refresh error.
•Show a targeted **Try again** action for failed secondary-data refreshes. Google calendar selection retains the selection on save failure, exposes the error at the correct step, and displays a saving indicator.
•Treat `timed_out` as terminal and manually retryable throughout cards, progress indicators, polling, cancellation, and stream handling. Stream reconnection uses an actual state transition, terminal chunks notify once outside React state updaters, and replaced/unmounted streams are aborted.
Persistence and recovery
•Patch connection and sync-run fields atomically instead of rewriting stale records. Maintain enabled connections and their schedules in transactions, and use consistent reads when returning updated connection or invite state.
•Write deduplicated event instances into a new generation, retry unprocessed DynamoDB batches, verify completeness, and conditionally publish the generation pointer. Concurrent publications cannot overwrite one another. Readers recheck the pointer and event count and retry if publication or cleanup overlaps a scan; strong scans alone do not provide snapshot isolation ([AWS reference](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Scan.html)).
+ 16 more lines...
azide0x37