Implement RegistrationPreferencesStore
epic-quick-activity-registration-data-infrastructure-task-004 — Implement RegistrationPreferencesStore on top of LocalStorageAdapter. Expose getLastUsedActivityTypeId() → Future<String?> and saveLastUsedActivityTypeId(String id) → Future<void>. This store is the sole persistence point for the pre-fill default that enables the two-tap happy path. Must handle null gracefully for first-time users with no saved preference.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Keep this class thin — it is a typed facade over LocalStorageAdapter, not a caching layer. Define a single private constant for the storage key. The two public methods are the entire public API; resist the temptation to add clearPreferences() or getAll() without a concrete consumer requirement. Use a const storage key like `_kLastActivityTypeKey = 'reg_prefs_last_activity_type_id'`.
The Riverpod provider (defined in task-006) should expose this as a simple `Provider
Testing Requirements
Unit tests using flutter_test with SharedPreferences.setMockInitialValues. Minimum test cases: (1) getLastUsedActivityTypeId returns null on empty store, (2) save then get round-trips correctly, (3) overwrite with new value returns latest, (4) store delegates to LocalStorageAdapter (verify via mock/spy, not real SharedPreferences). 100% branch coverage on the store class. No integration tests required for this component.
The optimistic insert pattern requires reconciling temporary local IDs with server-assigned IDs after the async Supabase write completes. If reconciliation logic is incorrect, the UI may display stale records, duplicate entries may appear, or subsequent operations (edit, delete) may target the wrong record ID, corrupting data integrity.
Mitigation & Contingency
Mitigation: Define a clear contract for temporary ID generation (e.g., UUID prefixed with 'local-') and implement a dedicated reconciliation method in ActivityRepository that atomically swaps the temporary ID. Write integration tests that simulate the full optimistic → confirm cycle.
Contingency: If reconciliation proves too complex, fall back to a simpler non-optimistic insert with a loading spinner for the network round-trip. The UX degrades slightly but correctness is preserved. Re-introduce optimistic behaviour once the pattern is stable.
Supabase row-level security policies on the activities table may not be configured to match the access patterns required by the client. If RLS blocks inserts or selects for the authenticated peer mentor session, all activity registration operations will silently fail or return empty results, which is difficult to diagnose in production.
Mitigation & Contingency
Mitigation: Define and test RLS policies in a dedicated Supabase migration script as part of this epic. Create integration tests that execute against a local Supabase instance with RLS enabled, covering insert, select by peer mentor ID, and denial of cross-mentor access.
Contingency: Maintain a fallback service-role client path (server-side only) that can be activated via a feature flag if client-side RLS is blocking legitimate operations while policies are corrected.
SharedPreferences on Flutter can become corrupted if the app crashes mid-write or if the device runs out of storage. A corrupted last-used activity type preference would cause the defaults manager to return null or an invalid ID, breaking the zero-interaction happy path.
Mitigation & Contingency
Mitigation: Wrap all LocalStorageAdapter reads in try/catch with typed safe defaults. Validate the retrieved activity type ID against the known list before returning it. Use atomic write operations where the platform supports them.
Contingency: If the preference store is corrupted, silently reset to the hardcoded default (first activity type alphabetically or 'general') and log a warning. The user loses their last-used preference but the app remains functional.