Settle whether a late TIM call can catch an aircraft swap

[atdr]

Unverified, and it decides whether a pre-departure sync is worth scheduling. The dataset stamp (+dated in model_version) does not move daily, but whether a flight's aircraft can change within a stamp is untested.

The raw sidecar records each distinct answer per flight, so a figure moving while dated holds steady would show it. See docs/emissions.md.

[atdr]

First data point, inconclusive:

contrail/docs/emissions.md

Lines 100 to 123 in c742f77

	## Watching for a real equipment swap: not yet caught
	The question above needs a flight where the airframe actually changes model, not
	just tail. Flighty's live app timeline exposes registration changes as they
	happen, ahead of departure.
	One short-haul flight was checked this way across its pre-departure daily syncs:
	`emissions_kg_*` and `aircraft_match` (`AIRCRAFT_MAPPING_EXACT`) were identical
	on every run, even though `model_version` bumped daily, confirming contrail
	really did re-ask TIM each time. But the app's tail history for that flight
	showed several registration changes, all resolving to the same model. So this
	was a null result for the test, not for TIM: there was no real equipment change
	for it to catch or miss. A stable figure under a non-event does not say whether
	TIM tracks a genuine swap promptly, tracks it slowly, or never updates within
	the window at all.
	**The blocker: Flighty's CSV export carries none of the tail history needed to
	find a real case.** Registration changes are only visible in the app's live
	timeline. The CSV importer reads a single `Aircraft Type Name` column, one
	snapshot value rather than a log, and tail number is explicitly out of storage
	scope (see `flighty_csv.py`). This cannot be settled from what contrail stores.
	It needs a flight, captured by hand from the app, that swaps model rather than
	tail, close enough to departure that a few daily syncs fall on either side of
	it. Wait for that flight.

One flight's Flighty app tail-swap timeline was cross-referenced against its daily pre-departure syncs. emissions_kg_* and aircraft_match stayed identical across five daily runs even though model_version bumped daily, confirming re-pricing genuinely happens. But every tail swap on that flight resolved to the same aircraft model, so there was no real equipment change for TIM to catch or miss — doesn't move this forward on its own.

Also surfaced a blocker for testing this further: Flighty's CSV export has no tail/model-history column (single Aircraft Type Name snapshot), so the swap timeline is only visible in the app. Settling this needs a flight with a genuine cross-model swap, captured by hand, close enough to departure that a few daily syncs fall on either side of it.