Feature Flag Local Cache

The Feature Flag Local Cache is low complexity but has two distinct storage layers—in-memory and persistent (local storage)—that each require separate testing strategies. The TTL mechanism must be validated for edge cases such as the app being suspended mid-TTL and resumed later. The persistent layer (`persist` / `loadPersisted`) requires a local storage library (e.g., SharedPreferences or Hive) to be established as a project dependency, which should be confirmed early to avoid late-stage dependency conflicts. Cache invalidation on organization context switch must be explicitly tested in integration scenarios involving account switching.

This component has no network dependency, so it is low deployment risk and can be developed in parallel with the repository.

FeatureFlagCache maintains two storage layers: a `Map` in memory where `_CacheEntry` holds `List` and a `DateTime` timestamp, and a persistent backing store (e.g., SharedPreferences with JSON serialization) for offline startup. `get(organizationId)` returns null if the key is absent or `isExpired` returns true. `isExpired` compares `DateTime.now().difference(entry.timestamp)` against the configured TTL constant (default 5 minutes). `persist` serializes flags to JSON and writes to the persistent store asynchronously—fire-and-forget from the provider's perspective.

`loadPersisted` is called at cold-start before the first network fetch to populate in-memory state. `invalidate` removes the in-memory entry only; `invalidateAll` clears both memory and persistent store. Keep TTL configurable via a constructor parameter to simplify testing with zero-second TTLs.