Implement DynamicsExporter: Field Mapping and Schema

HLF is coordinating this app with an existing Dynamics portal project — the `DynamicsMappedRecord` field names MUST match the Dynamics portal's import JSON schema exactly. Obtain the schema definition from HLF before implementing. Like `XledgerExporter`, never use `double` for amounts — use `Decimal` or integer øre. The `transaction_reference` generation should use `sha256(claimId + orgId)` truncated to 20 characters and uppercased — this makes it deterministic, unique per org+claim, and free of PII.

Store the `DynamicsSchemaMapper` config in a versioned assets JSON file under `assets/accounting/dynamics_schema.json` — same pattern as the Xledger chart of accounts mapper. Both HLF-specific validation rules (travel distance, automatic approval threshold) should be isolated in `DynamicsExporter` and NOT leak into the shared `AccountingExporter` interface. Consider extracting a `HlfExpenseRuleValidator` helper class to keep the exporter's `export()` method readable.

Unit tests using `flutter_test`. Required scenarios: (1) happy path — 4 standard claims map to correct `DynamicsMappedRecord` values; (2) travel claim with distance_km maps `travel_distance` field correctly; (3) travel claim missing distance_km produces `ValidationError` for `distance_km` field; (4) claim with unmapped category produces `ValidationError` with category name; (5) batch with mixed valid/invalid claims collects all failures; (6) `transaction_reference` is deterministic — same claim ID always produces same reference; (7) transaction_reference does not contain personal data (assert it equals a hash, not a name string). Use a stub `DynamicsSchemaMapper`. Minimum 10 unit tests.