Cache sync strategy and staleness invalidation logic

Implement `SummarySyncService` as an `AsyncNotifier` in Riverpod so its state (last sync result) is observable. Register a `WidgetsBindingObserver` inside the notifier's `build()` method and remove it in the `dispose()` hook — this handles the foreground trigger without leaking. To react to write events, expose a stream or `StateNotifier` from the aggregation repository and `listen()` to it inside the sync service — use `ref.listen` in Riverpod to keep this reactive. The `ensureFresh` method should be a read-through cache: check staleness → if fresh return local data → if stale fetch remote → update cache → return updated data.

Use a `Mutex` or `Completer`-based lock to prevent concurrent `syncNow` calls from racing (two rapid foreground events should not issue two simultaneous Supabase queries). Keep `SyncResult` as an immutable value object (use `freezed` if already a project dependency).

Write flutter_test unit tests with mocked `SummaryPeriodRepository` and `SummaryCacheRepository` (using Mockito or manual fakes): (1) ensureFresh returns cached data without calling remote when cache is fresh; (2) ensureFresh calls syncNow when isCacheStale returns true; (3) syncNow calls cacheSummaries with the fetched models; (4) syncNow catches SocketException, marks cache stale, returns SyncResult with failed_count > 0; (5) foreground lifecycle event triggers syncNow; (6) post-write invalidation then sync sequence produces correct final state; (7) syncNow called twice produces idempotent result. Also write one integration test (using the local Supabase emulator from task-011) that verifies the full sync cycle end-to-end.