Add session-scoped in-memory cache to OrganizationRepository
epic-organization-selection-and-onboarding-data-layer-task-003 — Implement a session-scoped in-memory cache within OrganizationRepository that stores the fetched organization list after the first successful network call. Subsequent calls within the same session return the cached list immediately without a network round-trip. Include cache invalidation logic triggered by auth state changes (sign-out clears cache). Cache must be keyed per authenticated user to prevent cross-user data leakage.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Use a private `final Map
Avoid using a global/singleton cache — the repository instance itself is the scope boundary, managed by Riverpod.
Testing Requirements
Write unit tests in flutter_test covering: (1) first fetch hits network and populates cache, (2) second fetch returns cached value with zero additional network calls (use Mockito mock of SupabaseClient), (3) sign-out event clears the correct cache entry while leaving other users' entries intact, (4) fetch failure leaves cache empty and next call retries. Aim for 100% branch coverage on the cache logic. No integration tests required at this layer — mocked Supabase client is sufficient.
TenantSessionStore must write to both SecureStorageAdapter and Supabase session synchronously. If the Supabase write succeeds but the local secure storage write fails (or vice versa), the system ends up in an inconsistent state: local app thinks org A is selected but Supabase queries are scoped to org B (or unscoped), causing silent data leakage or empty result sets.
Mitigation & Contingency
Mitigation: Implement the dual-write with compensating rollback: if the second write fails, undo the first write and surface a typed DualWriteFailureError to callers. Add a startup integrity check in restoreSession() that validates local storage and Supabase session agree on the current org_id.
Contingency: If integrity check fails on startup, clear both stores and redirect the user to the org selection screen rather than proceeding with potentially mismatched state.
An organization could be deactivated in Supabase between the time the org list is cached and the time the user taps to select it. If the repository serves stale cached data the org-selection-service will attempt to seed a context for an inactive org, potentially causing RLS scope issues or confusing error states.
Mitigation & Contingency
Mitigation: The OrganizationRepository.getOrganizationById() path used during selection validation always performs a fresh network fetch (bypassing cache) to confirm the org is still active before the TenantSessionStore writes anything.
Contingency: If a freshness check finds the org is inactive, surface a localized error message on the selection screen ('This organization is no longer available') and refresh the org list to show only currently active partners.