Implement Dynamics Exporter service

Mirror the XledgerExporter architecture but with a DynamicsRecordMapper producing DynamicsJournalLine objects. The key difference from Xledger: Dynamics uses a single-row-per-claim format (no double-entry pair) with amount as a signed decimal (positive for expenses). Define DynamicsJournalLine as an immutable Dart class with the 7 required fields. Use the same pipeline pattern: map → validate → serialize → upload → record → return.

The ChartOfAccountsMapper should be capable of resolving both Xledger account codes and Dynamics ledger account / dimension codes from the same org configuration — confirm this is in scope when ChartOfAccountsMapper is implemented (task-004). Reuse CsvJsonFileGenerator from task-005 with a DynamicsColumnSchema configuration object. Keep the two exporters as sibling classes implementing a shared abstract AccountingExporter interface — this allows the Accounting Exporter Service to call them polymorphically. The interface: Future export(String orgId, List claims).

Store Dynamics-specific field length constants (60 char description limit) in a DynamicsExportConstants class rather than magic numbers.

Unit tests (flutter_test with mocked dependencies): test DynamicsRecordMapper.toDynamicsJournalLine(claim) for mileage and toll claim types; assert currency is 'NOK'; assert description truncation at 60 chars; assert missing ledger account moves claim to unresolvable list; assert zero-amount claim triggers validation failure. Integration test: invoke full export() with 5 mock ApprovedClaims against test Supabase Storage; verify file created and export_runs record has status 'completed'. Test file: test/services/dynamics_exporter_test.dart. Mock ChartOfAccountsMapper and CsvJsonFileGenerator.

Confirm DynamicsExporter and XledgerExporter share no logic beyond the injected ChartOfAccountsMapper and CsvJsonFileGenerator — they must remain independently testable.