Extend OrganizationLabelsProvider for activity types
epic-activity-type-configuration-foundation-task-008 — Extend the existing OrganizationLabelsProvider (075-organization-labels-provider) to support activity type display name overrides. Organisations like HLF and Blindeforbundet use different terminology for the same activity type concepts. The provider must resolve the display name for a given activity type ID and org context, falling back to the canonical name when no override exists.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Read the existing 075-organization-labels-provider implementation fully before modifying it — the extension must match the existing patterns (naming, error handling, caching strategy). The cleanest approach is to add an `activityTypeLabels` map to the existing labels data structure loaded from Supabase, keyed by activity_type_id. If the org_labels Supabase table does not yet have an activity_type_labels column or table, add a TODO for the database migration and use an empty map as the default. The fallback chain is: (1) org-specific override from Supabase → (2) ActivityType.name from the domain model.
Do not introduce a third fallback layer. For caching, use a private Map
Testing Requirements
Unit tests with flutter_test and MockSupabaseClient: (1) getActivityTypeDisplayName returns org-specific override when one exists in the mock data; (2) getActivityTypeDisplayName returns canonical ActivityType.name when no override exists; (3) getActivityTypeDisplayName returns canonical name when the overrides data source returns an empty list; (4) network error during override load — assert canonical name is returned and no exception propagates; (5) cache hit — second call for same orgId does not trigger a second Supabase query (verify mock is called only once); (6) cache invalidation — after org switch, stale overrides are not returned. Widget test: render an activity type name in a widget using the provider and assert the overridden label appears for HLF's org context.
The JSONB metadata column has no enforced schema at the database level. If the Dart model and the stored JSON diverge (e.g., a field is renamed or a new required flag is added without a migration), the metadata resolver will silently return null or throw at parse time, breaking conditional wizard logic for all organisations.
Mitigation & Contingency
Mitigation: Define a versioned Dart Freezed model for ActivityTypeMetadata and add a Supabase check constraint or trigger that validates the JSONB structure on write. Document the canonical metadata schema in a shared constants file and require schema review for any metadata field additions.
Contingency: Implement a lenient parse path in ActivityTypeMetadataResolver that returns safe defaults for missing fields and logs a structured warning to Supabase edge logs, allowing the app to degrade gracefully rather than crash.
If RLS policies on the activity_types table are misconfigured, a coordinator from one organisation could read or mutate activity types belonging to another organisation, violating data isolation guarantees required by all three client organisations.
Mitigation & Contingency
Mitigation: Write integration tests against the Supabase local emulator that explicitly assert cross-org isolation: a token scoped to org A must receive zero rows when querying org B activity types, and upsert attempts must return permission-denied errors.
Contingency: Apply an emergency RLS policy patch via Supabase dashboard without a code deploy. Audit all activity_type rows for cross-org contamination and restore from backup if any data leakage is confirmed.
If the cache invalidation call in ActivityTypeService is not reliably triggered after an admin creates, edits, or archives an activity type, peer mentors on the same device will see stale data in the registration wizard until the next app restart, leading to confusion and potential misregistrations.
Mitigation & Contingency
Mitigation: Enforce a strict pattern: ActivityTypeService always calls cacheProvider.invalidate() inside the same try block as the successful Supabase mutation, before returning to the caller. Write a widget test that verifies the cache notifier emits an updated list after a service mutation.
Contingency: Add a background Supabase Realtime subscription on the activity_types table that triggers cache invalidation automatically, providing an independent safety net independent of the service call path.