Add flight-day detector + richer "Fix this day" screen

[kyleve]

What & why

Adds a speed-based flight-day classifier to the Resolve tab. When you fly, passive GPS drops cruise-speed fixes across regions you only passed over — e.g. a NYC→SF flight adds a spurious .other (the fly-over states collapse to Elsewhere since the Region enum only models CA/NY/Canada/EU). This detects those days and offers a one-tap fix.

It also enriches the shared "Fix this day" screen (DayRelabelView) with a map of the day's recorded points and a classifier-driven "why" banner, so every resolution flow — not just flights — shows where the GPS points actually were and why the day was flagged.

Validated against a real July 14 backup: cruise legs of 590–898 km/h (a 1,346 km leg in 90 min) vs. ground/noise blips topping out at ~116 km/h. A ~300 km/h threshold + ~80 km min-leg-distance separates flight from driving and from GPS teleport glitches with a wide margin.

How it works

Store samples ─▶ ReportReader.samples(inYear:) ─▶ DataIssueScanner
                                                    │ builds DataIssueInput.daySamples
                                                    │ (timestamped, GPS-only)
                                                    ▼
                                            FlightDayDetector
                                                    │ .correctFlightDay(keep, removed, peak)
                                                    ▼
                              ResolutionView ─▶ FlightDayDetailView
                                                    ├─ map of the day's points (fly-over tinted apart)
                                                    ├─ one-tap "Apply — keep New York, California"
                                                    ├─ "Not what you expected?" ─▶ DayRelabelView
                                                    └─ "These are all correct" (dismiss)

• A fix is a fly-over when the legs on both sides clear ~300 km/h over ≥80 km; a region is spurious when all its fixes are fly-overs (endpoints/dwell keep a non-fly-over fix). Requires ≥2 fly-over fixes so a lone teleport glitch doesn't read as a plane, and only fires when ≥1 region is removed and ≥1 survives.
• "Apply" writes an authoritative overrideDay keeping only the endpoints (reversible — raw samples untouched).
• RecordedPointsMap was extracted from RegionDaysView and is now shared by the Elsewhere drill-in, the flight detail view, and DayRelabelView.

Design decisions

• Bespoke, dismissible flight detail view (rather than dumping into the manual relabel form) with a one-tap apply, and a "Not what you expected?" escape hatch into DayRelabelView seeded from the day's actual regions (so a wrong guess isn't baked in).
• v1 = same-calendar-day flights. Overnight/international flights that cross midnight are deferred (they interact with the abrupt-change detector) and noted as a limitation.

Testing

• New FlightDayDetector unit tests: flags the NYC→SF profile (keeps {NY, CA}, drops .other, peak >300); ignores fast driving, a lone teleport glitch, a mid-flight-only day, and a legitimate layover.
• DayAggregator.pointsByRegion tests; Coordinate.distance great-circle tests.
• End-to-end ResolveModel tests: a seeded flight surfaces through the real scanner; applying the fix clears the issue (idempotence); manual/evidence samples are excluded from the speed math.
• FlightDayDetailView hosting test + previews.
• ./swiftformat --lint clean; RegionKitTests, WhereCoreTests, WhereUITests, and the full Stuff-iOS-Tests scheme all pass locally.

Notes / limitations

• Same-day only (see above).
• At a high driftThresholdMeters, a near-border fly-over fix could make both the border-drift and flight detectors fire for the same day (two rows); resolving either clears both. Minor UX, self-resolving.
• New Strings use the codebase's inline String(localized:defaultValue:) pattern; catalog translations populate via Xcode extraction.