refactor(theme): provide ThemeSettings as an inherited value, out of AppState

[SERDUN]

Overview

Moves the active ThemeSettings out of AppState and provides it as an inherited value at the composition root, so the app consumes it directly through the widget tree — the same pattern already used for FeatureAccess.

The theme settings were static for a whole run (seeded once from AppThemes, never changed at runtime), yet lived in AppState; the only code that ever emitted AppThemeSettingsChanged was external. This refactor makes RootApp the single injection boundary for the theme and keeps everything below it consuming via providers — no bloc relay.

This is groundwork for host-driven theming (an embedder overriding the provider); standalone behaviour is unchanged.

Changes

• RootApp provides Provider<ThemeSettings> (standalone: AppThemes.values.first.settings). An embedder can override this provider to drive the theme.
• App.build and ThemeModeScreen read context.watch<ThemeSettings>() instead of AppState.themeSettings.
• isThemeModeSupported / effectiveThemeMode move from AppState getters to a ThemeSettings extension (they depend only on the settings plus the mode).
• AppState keeps only themeMode (still user-switchable and persisted). Dropped: the themeSettings field, the AppThemeSettingsChanged event + handler, and the now-unused AppThemes dependency of AppBloc.

Verification

• flutter analyze — clean.
• Full test suite — 940 pass (theme-mode screen, teardown, version-gate and app-compatibility-gate tests updated to the new shape).
• ThemeProvider.of consumers (e.g. themed_scaffold) unaffected — the ThemeProvider widget still wraps MaterialApp.