Avoid repeated global filtering in schedule date streams

[jjoonleo]

Problem

ScheduleRepositoryImpl maintains one global schedule stream, while GetSchedulesByDateUseCase filters and sorts the full emitted schedule set inside each subscriber. Weekly and monthly consumers therefore repeat range filtering and sorting on every schedule emission, even when only one date window changed.

Evidence

• lib/data/repositories/schedule_repository_impl.dart seeds a singleton BehaviorSubject<Set<ScheduleEntity>> and exposes it as scheduleStream.
• Range loads update the shared global set and emit the whole merged set.
• lib/domain/use-cases/get_schedules_by_date_use_case.dart subscribes to that global stream, filters by [startDate, endDate), sorts the filtered list, and yields it per subscriber.
• lib/presentation/home/bloc/weekly_schedules_bloc.dart and lib/presentation/calendar/bloc/monthly_schedules_bloc.dart create separate date-range subscriptions.

Proposed direction

Introduce a range-aware schedule watch path so filtering and sorting are not repeated independently by every UI subscriber. Options include moving watchSchedulesByDate(startDate, endDate) into the repository, maintaining sorted/range-indexed derived streams, or sharing/distincting date-range projections in the domain layer.

Preserve the existing load path separately: loading fetches or refreshes data, watching returns an already scoped sorted stream.

Acceptance criteria

• Date-range consumers can subscribe to schedules without each subscriber independently filtering and sorting the full global schedule set.
• Existing behavior is preserved: start date inclusive, end date exclusive, sorted by scheduleTime.
• Create/update/delete/range-load mutations still update active weekly and monthly views correctly.
• Tests cover multiple active date-range subscribers and verify unrelated range updates do not cause incorrect visible results.
• Presentation still depends on use cases, not data sources.

Source: Codex codebase audit on 2026-06-28.