Implement BulkApprovalProcessor service core

The core pattern is: iterate sequentially (or with bounded parallelism), wrap each delegation call in try/catch, accumulate into a mutable result builder, return immutable result at end. Start with sequential processing (simpler, easier to reason about) and only switch to Future.wait if performance testing shows it's needed — the coordinator use case typically involves < 100 claims. Map Supabase PostgreSQL error codes to BulkApprovalErrorCode in a dedicated mapper function (e.g., _mapSupabaseError) to keep the processor clean. Use Stopwatch for processingDurationMs.

Do not use Riverpod state inside the service itself — it should be a plain Dart class registered as a Riverpod provider from outside.

Unit tests (with mocked ApprovalWorkflowService): (1) all-success batch returns correct successCount, (2) all-failure batch returns correct failureCount with no successful IDs, (3) mixed batch — 3 succeed, 2 fail — returns accurate split, (4) exception thrown by ApprovalWorkflowService is caught and does not propagate, (5) empty input returns zero-count result without calling service, (6) duplicate ID detection. Integration tests against Supabase test project: (1) approve a batch of 3 pending claims and verify claim_event rows created for each, (2) batch including a non-existent claim ID produces partial failure result. Place unit tests in test/domain/services/expense/ and integration tests in test/integration/expense/.