Implement ExpenseClaimStatusRepository with optimistic locking

Optimistic locking with Supabase: use `.update(payload).eq('claim_id', claimId).eq('version', currentVersion)` — the version filter means 0 rows affected = conflict. Supabase's `.update()` does not return a count by default; use `.select()` chained after `.update()` to get the updated row back, then check if the list is empty (conflict) or has one item (success). Do NOT use a separate SELECT to check version before UPDATE — this creates a TOCTOU race condition that defeats the purpose of optimistic locking. For Realtime, use `supabase.channel('claim-status-$claimId').onPostgresChanges(...)` scoped to `filter: 'claim_id=eq.$claimId'`.

In the stream transformer, parse the payload directly from the Realtime event rather than issuing a follow-up SELECT, to minimize latency and round-trips. Provide a StreamController wrapper that handles the Supabase RealtimeChannel lifecycle (subscribe on listen, unsubscribe on cancel) within a single Dart Stream.

Unit tests using flutter_test and mock SupabaseClient: getStatus() success, getStatus() with empty result throws ClaimNotFoundException, updateStatus() with matching version succeeds, updateStatus() with mismatched version throws OptimisticLockException with re-fetched status, watchStatus() emits values on stream, stream cancellation removes Supabase Realtime subscription, InvalidTransitionException thrown before network call for disallowed transitions, all three retry scenarios for network errors. Integration tests: concurrent update simulation — two clients read version=1, first update succeeds returning version=2, second update returns OptimisticLockException, Realtime stream emits event within 2 seconds of direct database UPDATE, stream reconnects after simulated network drop.