Implement OrganizationUnitRepository with CRUD and tree queries

Define OrganizationUnitRepository as an abstract class so BLoC and use-case code depends on the abstraction, not the Supabase implementation. This is essential for unit testing the BLoC layer without a real database. Use Riverpod's Provider or AsyncNotifierProvider to expose the repository — follow the existing provider pattern in the project. Error mapping: wrap all Supabase calls in try/catch, inspect the exception type (PostgrestException, SocketException, etc.) and rethrow as domain exceptions.

For soft-delete filter: use .filter('deleted_at', 'is', null) in Supabase queries — do not rely on a database view unless one already exists. For restoreUnit, use .update({'deleted_at': null}) — confirm Supabase Flutter SDK handles null updates correctly (it does as of supabase_flutter 2.x). The repository should not contain business logic (e.g., permission checks beyond what RLS enforces) — keep it a thin data access layer. Do not cache data in the repository; caching belongs in the BLoC or use-case layer if needed.

Write unit tests using flutter_test with a mock Supabase client (implement a FakeOrganizationUnitRepository conforming to the abstract interface). Test scenarios: (1) fetchUnit returns OrganizationUnit on success. (2) fetchUnit returns null when Supabase returns empty list. (3) fetchUnit throws OrganizationUnitNotFoundException when record is soft-deleted.

(4) fetchSubtree builds correct OrganizationUnitTree from flat RPC response. (5) createUnit returns created entity with server-assigned id. (6) softDeleteUnit succeeds and subsequent fetchUnit returns null. (7) Supabase network error maps to NetworkException.

(8) Supabase 403 maps to PermissionException. Write at least one integration test against a local Supabase instance that exercises the full round-trip: create → fetch → softDelete → confirm deleted. Use flutter_test for all tests.