docs: add task 3 report

.superpowers/sdd/task-3-report.md

@@ -0,0 +1,50 @@
+# Task 3 Report: Final Mileage Election Projector
+
+## Outcome
+
+Implemented `ProjectDailyMileage` in `go/vehicle-gateway/internal/stats/source_mileage.go` and added focused projector coverage in `go/vehicle-gateway/internal/stats/source_mileage_test.go`.
+
+## RED
+
+Before implementation, the new projector test failed as expected because the function did not exist yet:
+
+```text
+internal/stats/source_mileage_test.go:87:9: undefined: ProjectDailyMileage
+```
+
+That confirmed the test was exercising the missing task-3 surface rather than passing accidentally.
+
+## GREEN
+
+After implementation:
+
+- `go test ./internal/stats -run TestProjectDailyMileageSelectsCandidateAndMarksSource -count=1`
+- `go test ./internal/stats -count=1`
+
+Both passed.
+
+## What Changed
+
+- Added `maxSelectedDailyMileageKM = 1000`.
+- Added `ProjectDailyMileage(...)` with three SQL steps:
+  - clear `is_selected` for the VIN/date/protocol slice,
+  - project the elected row from `vehicle_daily_mileage_source` into `vehicle_daily_mileage`,
+  - mark the winning source row as selected.
+- Kept the candidate identity intact: `source_key` still carries protocol + phone/device + source IP, while the data-source join uses protocol + source IP.
+- Added a focused test that asserts the clear/project/mark sequence and the key SQL fragments.
+
+## Files Changed
+
+- `go/vehicle-gateway/internal/stats/source_mileage.go`
+- `go/vehicle-gateway/internal/stats/source_mileage_test.go`
+
+## Self-Review
+
+- The projector stays aligned with the existing stats schema and helper conventions.
+- The SQL ordering and join logic preserve the intended source identity split; there is no IP-only simplification.
+- I did not add an unrelated schema migration because the current repository state already contained the needed `vehicle_daily_mileage_source` and `vehicle_daily_mileage` columns/indexes for this projector.
+- The only notable follow-up risk is that the final selection query relies on MySQL-style `INSERT ... SELECT ... LIMIT 1 ON DUPLICATE KEY UPDATE` behavior, which matches the rest of the stats package but should still be exercised against the target DB in an integration run.
+
+## Commit
+
+`aa12317b5` - `feat(stats): project elected mileage source`