feat: Phase 3 — Dawarich location-history validation (advisory)

[constgemm]

Uses your Dawarich point history as an independent second signal on each parsed candidate — the same thing a flight-tracker app gets from GPS, but self-hosted.

Logic (safe by design)

• Points near the destination (or origin) within ±1 day, 100 km → confirmed.
• Tracking clearly active that day but nowhere near either endpoint (≥5 points, and we had a coordinate to test) → contradicted = likely cancellation/rebooking.
• No airport coordinate, or no points in the window → unknown. Absence of data is never a false alarm.

It only annotates (candidate["location"]) and, on a contradiction, adds a review issue — which also trips _blocked_reason, so a contradicted flight can't slip into --auto-write. It never changes confidence and never writes or deletes anything.

Changes

• airdata.py — approximate airport coordinates (~130 airports) + airport_latlon() (accepts IATA or ICAO). Metro-area precision is enough for a 100 km test; gaps degrade to "unknown".
• dawarich.py — config, tolerant /api/v1/points fetch (bare list / wrapped / GeoJSON), haversine, classifier.
• populate.py — opt-in validate step (DAWARICH_VALIDATE=1 or --validate); digest shows a 📍 marker.
• Dockerfile, .env.example, README.
• tests/test_dawarich.py — 16 tests. Suite on this branch: 45 green.

Touches the same populate.py import block + main() as the Phase 2 PR (#7), so whichever merges second will need a trivial conflict resolve.

Needs from you to actually run: Dawarich base URL + API key (→ .env).

🤖 Generated with Claude Code