Write unit and widget tests for theme assembly

Use Riverpod ProviderContainer (not ProviderScope) for unit tests to keep tests fast and isolated — create a fresh container per test with override() to inject fixture branding configs. For ColorScheme mapping tests, define expected values as constants derived directly from the design token JSON files (parse them in a test helper) rather than hardcoding hex strings — this creates a single source of truth and makes token drift immediately visible. For contrast validation tests, create a test helper `expectContrastRatio(Color fg, Color bg, {double minRatio})` that computes relative luminance using the W3C formula — this is more reliable than relying solely on the accessibility matcher which works on rendered pixels. For widget tests, use `tester.pump()` rather than `pumpAndSettle()` where possible to keep tests fast; only use `pumpAndSettle()` when testing animated transitions.

Group tests with Dart's `group()` by organisation name to make CI output readable. Consider parameterizing org×brightness combinations with a helper to avoid 8 copies of near-identical test bodies — use a list of test cases and a loop calling `testWidgets()`.

This task IS the testing task. Self-validation: run `flutter test test/theme_builder_test.dart --coverage` and confirm 0 failures and >= 90% coverage. Peer review checklist: each test has a descriptive name following the pattern 'given_[state]_when_[action]_then_[expectation]'; no test shares mutable state with another; all widget tests call tester.pumpAndSettle() before making assertions; accessibility matcher failures produce a meaningful error message identifying which org/brightness combination failed. Regression gate: add a comment block in the test file listing the design token file hashes that the mapping tests were written against, so future token updates are flagged.