Expose token provider via Riverpod providers

Use Riverpod's @riverpod code generation annotation if the project already uses riverpod_generator — this produces type-safe provider references and eliminates boilerplate. If using manual Provider() syntax, declare providers in a dedicated file (lib/design_system/providers/design_token_providers.dart) and avoid placing them in the same file as the DesignTokenProvider class to maintain separation of concerns. For the immutability guarantee in production, use Dart's const constructor on the provider's return value and avoid exposing any setter or mutable state. For the multi-org scenario, the organisationThemeProvider should be a StateProvider (or derived from the auth/session provider that knows the current user's organisation) — designTokenProvider should use ref.watch(organisationThemeProvider) internally and return the appropriate DesignTokenProvider instance.

Document in the barrel file's README comment that ProviderScope must be placed at the root of the widget tree (above MaterialApp) to ensure all widgets have access.

Write widget tests using ProviderScope with overrides to test both: (1) the default org theme returns the expected DesignTokenProvider instance with correct token values; (2) overriding organisationThemeProvider with a different OrgTheme value causes designTokenProvider to return a different color set. Write a unit test using ProviderContainer (no widget tree) to assert the provider resolves synchronously. Add a golden test that renders a simple widget consuming tokens via the provider and compare it against a committed golden image for each supported org theme — this prevents silent visual regressions when token values change.