Add Filter Change Event Handling to StatsBloc

StatsFilter should be a @immutable value class with a copyWith method. Implement preset-to-DateTimeRange resolution as a getter on StatsFilter (e.g. StatsFilter.resolvedRange) so the date math is computed once. For cross-BLoC filter propagation, inject PersonalStatsBloC into StatsBloc constructor: `StatsBloc({required CoordinatorStatsService service, required PersonalStatsBloC personalStatsBloc})`.

This is simpler and more testable than using an EventBus or shared Riverpod provider. For BlocProvider placement: in GoRouter, use the `builder` parameter at the route level to wrap the screen with BlocProvider. Do not use `MultiBlocProvider` inside the screen's build method — that recreates the BLoC on every rebuild. Debounce implementation: `on((e, emit) async { _activeFilter = e.filter; await _reload(emit); }, transformer: debounce(const Duration(milliseconds: 300)))`.

The 300ms debounce covers the date picker scrolling UX pattern common in Flutter mobile apps.

Unit tests using flutter_test + bloc_test + mocktail. Test cases: (1) FilterChanged with last30d preset → correct DateTimeRange computed and passed to service, (2) FilterChanged with custom range → service called with exact custom dates, (3) two FilterChanged events within 300ms → only one service call made, (4) invalid custom range (start after end) → StatsError emitted with descriptive message, (5) custom range exceeding 366 days → StatsError emitted, (6) FilterChanged propagates to mocked PersonalStatsBloC (verify PersonalStatsFilterChanged added), (7) filter preset maps to correct date arithmetic (last30d = 30 days inclusive), (8) active filter echoed on StatsLoaded state. Widget test: verify BlocProvider placed above route preserves BLoC instance across Navigator.push/pop.