Unit and integration tests for API client

Structure tests in three files mirroring the production structure: `bufdir_request_mapper_test.dart` (pure unit, no I/O), `bufdir_auth_handler_test.dart` (unit with mocked token store), `bufdir_api_client_integration_test.dart` (mock HTTP server). Use Dart's `http` package MockClient for HTTP stubbing — avoid real HttpServer unless response streaming behaviour must be tested. For the retry integration test, use a stateful counter in the mock handler that returns 500 for the first N calls then 200, and assert the counter reached the expected value. For Supabase persistence assertions, inject a mock repository implementing the same interface as the real one (follow the repository pattern already established in the codebase).

Keep test data in `test/fixtures/bufdir/` as JSON files to keep test methods readable. Do not use `print` in tests — use `fail()` with descriptive messages instead.

Unit tests: cover every public method on the API client class using flutter_test with mocked HTTP and mocked Supabase repository. Integration tests: spin up a local MockClient or dart:io HttpServer that returns scripted HTTP responses (200 with reference number, 422 with validation body, 500 then 200 on retry). Use setUp/tearDown to isolate test state. Assert both the returned Dart objects and side-effects (repository.persist called with correct reference number).

Coverage: run `flutter test --coverage` and use lcov or the built-in reporter to confirm the 90% threshold. Failure modes to test: network timeout, malformed JSON response body, missing reference_number field in success response.