Expense Claim Status Repository

Medium complexity, this component's most significant delivery risk is the correct implementation of optimistic locking via the `updateStatus` interface, which accepts an `expectedCurrentStatus` parameter and must return a conflict error if the database value has changed since the caller last read it. This pattern requires careful integration testing under concurrent request scenarios, which should be included in the QA plan. The paginated `getPendingClaims` query will need performance testing against realistic data volumes to ensure coordinator queue load times meet UX requirements. This component is a hard dependency for the approval workflow service and the coordinator queue screen, so it sits on the critical path and should be prioritised for early completion to unblock downstream development.

This repository provides targeted, narrow-scope access to the `status` field on the `expense_claims` table, deliberately avoiding full-object reads to minimise data transfer overhead in high-frequency workflow operations. The `updateStatus` method implements optimistic concurrency control: it issues an `UPDATE ... WHERE id = claimId AND status = expectedCurrentStatus` and checks the affected row count — zero rows updated indicates a concurrent modification conflict, which must be surfaced as a typed error (`OptimisticLockConflictError`) for the calling service to handle. `getPendingClaims` and `getClaimsByStatus` must accept `organisationId` as a mandatory scope parameter and be validated against RLS policies to prevent cross-organisation data leakage.

Index coverage on `(organisation_id, status, created_at)` is required for efficient paginated queries; verify the Supabase migration includes this composite index.