Activity Type Cache Provider

This component has medium complexity and sits on the critical path for both the registration wizard and any admin-facing activity type mutation flows. It depends on the Activity Type Repository, so that repository must be stable and tested before this provider can be fully validated. The Riverpod state management pattern requires developers familiar with Flutter's reactive paradigm — factor this into team assignment. Testing must cover cache warm-up on login, correct serving of cached data to consumers, invalidation logic triggered by admin mutations, and refresh behavior after network failures.

Since this is a shared component consumed by multiple features, any regressions will have broad impact; allocate time for integration testing across all dependent screens. Deployment risk is low once stable, but initial implementation should include monitoring for stale data edge cases to avoid user-facing inconsistencies.

Implemented as a Riverpod `AsyncNotifier`, this provider manages the full lifecycle of activity type data for the authenticated session. On `build()`, it delegates to `activity-type-repository` to fetch the organisation's activity types and holds them in memory. `getActivityTypes()` and `watchActivityTypes()` expose the cached state reactively to widgets and services without triggering additional network requests. `invalidateCache()` is called by the service layer after any admin mutation, which internally triggers `refresh()` to re-fetch from the repository.

The reactive model ensures all watchers automatically receive updated data post-invalidation. Because this is a shared provider consumed across the registration wizard and other flows, care must be taken to avoid over-invalidation. Error states from the repository (network failures, auth errors) propagate through Riverpod's `AsyncValue` error channel and must be handled at each consumer site.