Clarify unused schedule local data source architecture

[jjoonleo]

Problem

ScheduleRepositoryImpl still injects ScheduleLocalDataSource, but the repository does not actively use it for schedule reads or writes. This makes the app look like it has an offline/local-cache schedule architecture even though schedule repository behavior is currently remote-first plus in-memory stream updates.

Evidence

• ScheduleRepositoryImpl imports and injects ScheduleLocalDataSource.
• The only local write calls in the repository are commented out for create, delete, and update.
• Active reads go directly to scheduleRemoteDataSource.getScheduleById and scheduleRemoteDataSource.getSchedulesByDate, then update only the in-memory BehaviorSubject.
• ScheduleLocalDataSource exposes full CRUD/read methods backed by the local schedule DAO, so the unused injection suggests a cache/offline contract that is not actually enforced.

Proposed direction

Decide whether local schedules are a supported cache/offline layer. If yes, wire the repository to read/write the local data source with explicit freshness and fallback behavior. If no, remove the unused repository dependency and commented calls, and keep schedule persistence responsibilities clearly remote-only.

Acceptance criteria

• ScheduleRepositoryImpl no longer contains commented-out local schedule calls.
• The repository either actively uses ScheduleLocalDataSource with tested cache/fallback semantics, or does not inject it at all.
• Tests cover the chosen behavior for create, update, delete, getScheduleById, and getSchedulesByDate.
• Architecture comments/docs do not imply offline schedule support unless it is implemented and tested.

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