Implement Xledger REST adapter

Implement inside a Supabase Edge Function (Deno) — never in the Flutter client. The adapter should be a Deno class that accepts an AdapterConfig object at construction (credentials resolved from vault, not passed directly). Use Deno's built-in fetch for HTTP calls. For OAuth2, implement a lightweight client credentials grant without third-party OAuth libraries to keep the Edge Function bundle small.

Xledger uses a REST API with JSON bodies — construct payloads by mapping from internal expense/activity models. Key pitfall: Xledger's cost centre and account code fields are organisation-specific — store these as part of the integration configuration (not hardcoded). Map the activity's organization_id to the Xledger company code stored in the credential vault entry. Implement the adapter's execute() method with a command pattern: accept an AdapterCommand enum (EXPORT_EXPENSE, EXPORT_ACTIVITY) and dispatch to private handler methods.

This keeps the public interface clean while allowing internal routing. For error normalization, create an XledgerErrorMapper that converts HTTP status + body to AdapterError with a code, message, and retryable boolean. Use the retryable flag in the retry loop to skip retrying on 401/403.

Unit tests (flutter_test / Deno test): payload serialization for Xledger accounting entry format, OAuth2 token acquisition and refresh flow (mocked HTTP), error normalization for all Xledger error response shapes (400, 401, 403, 429, 500, 503), retry logic verifying exponential backoff timing and max-retry enforcement. Integration tests: full OAuth2 flow against Xledger sandbox, accounting entry creation with valid Blindeforbundet test data, credential isolation test verifying cross-org access is rejected. Test coverage target: 90% on adapter business logic. All tests must run in CI without live Xledger credentials (use recorded HTTP fixtures for unit tests).