Route DAO access through repository layer (18 classes bypass repos)

## Problem

18 classes directly access `TreeTrackerDAO` and `MessagesDAO`, bypassing the repository abstraction layer (`UserRepo`, `MessagesRepo`, `OrgRepo`). This undermines the separation of concerns, makes testing harder, and means data transformation/validation logic in repositories is skipped.

## Affected Classes

- `DashboardViewModel` — direct DAO calls for tree counts
- `DashboardViewModel` (TreesToSyncHelper) — direct DAO for sync counts
- `MapViewModel` — direct DAO access
- `TreeUploader` — direct DAO calls
- `PlanterUploader` — direct DAO calls
- `SessionUploader` — direct DAO calls
- `DeviceConfigUploader` — direct DAO calls
- `SyncDataUseCase` — direct DAO access
- `CreateTreeUseCase` — direct DAO access
- `CreateFakeTreesUseCase` — direct DAO access
- `UploadLocationDataUseCase` — direct DAO access
- `CreateLegacyTreeUseCase` — direct DAO access
- And several others

## Suggested Fix

1. Identify query groups (tree queries, session queries, user queries, etc.)
2. Add appropriate methods to existing repositories or create new ones (e.g., `TreeRepo`, `SessionRepo`)
3. Route all DAO calls through repositories
4. Update DI module to inject repos instead of DAOs where appropriate

## Effort
High — requires careful refactoring across many files, but can be done incrementally per entity type.

Start by inventorying direct TreeTrackerDAO and MessagesDAO usage in the listed classes, then inspect UserRepo, MessagesRepo, OrgRepo, and the DI module. Group the calls by entity and determine which repository methods or new repositories are needed. Done means the affected classes receive repositories through DI rather than accessing DAOs directly.

Written by the indexing model from the issue text.