Integration test UserIdentityRepository and VippsOrgCostConfig against Supabase

The most complex aspect is managing test isolation with a live Supabase backend. Use a transaction-per-test pattern if supported, or implement a dedicated test seed/cleanup lifecycle. For the cross-user RLS test, you need two authenticated Supabase sessions simultaneously — use two separate Supabase client instances initialized with different user JWTs. The GDPR purge test should assert both that the remote row is deleted (or anonymized) AND that the local SecureStorage keys return null — test these as two separate assertions after calling purgeLocalData().

For personnummer, use the Norwegian SSN format (11 digits) with known test numbers that pass the mod-11 checksum algorithm. The VippsOrgCostConfig gate test is best placed after the UserIdentity tests since both use the same test Supabase project — coordinate the seed data to cover both test suites. Store test config in a .env.test file loaded via flutter_dotenv or equivalent, ensuring CI injects SUPABASE_TEST_URL and SUPABASE_TEST_ANON_KEY as environment variables.

Structure the test suite in integration_test/repositories/ with separate files: user_identity_repository_test.dart and vipps_org_cost_config_integration_test.dart. Use a shared test_supabase_helper.dart that handles: (1) initializing Supabase with test credentials, (2) signing in two distinct test users (test_user_a and test_user_b), (3) seeding vipps_org_cost_config rows for two orgs (one active, one inactive), (4) teardown that deletes seeded rows and signs out all users. Use group() blocks to organize tests by scenario. For the RLS test, sign in as test_user_b and attempt to query test_user_a's identity row using .eq('user_id', userA.id) — expect empty result or error.

For GDPR purge, verify both Supabase deletion and local SecureStorage clearance in a single atomic test scenario.