Decide the CAMM GPS epoch by the creation time, then the make

[caglarpir]

Split out of #842. Follow-up to #828.

Problems on main

1. Our own CAMM output of a Labpano video reads back ten years late. Fix GPS epoch vs Unix epoch mix-up when geotagging CAMM videos #828 writes Unix time for every make, but the CAMM track we write copies the make and the mvhd creation time of its source, and the reader converts every track whose make is exactly labpano from GPS time. mapillary_tools does not read its uploads back in normal use, so this shows in dry runs and when such a file is processed again.
2. Exact make match. A variant like Labpano Technology Co.,Ltd is not converted. Because the elst now widens to 64 bits instead of overflowing, such a file comes out ten years off silently.
3. Type 5 points dropped. Fixing the type routing in Fix GPS epoch vs Unix epoch mix-up when geotagging CAMM videos #828 split type 5 and type 6 points into mini_gps and gps, and the native extractor then uses gps or mini_gps, which drops the type 5 points when a track has both.

Changes

• The mvhd creation time decides the epoch when it is conclusive: GPS time reads as one GPS epoch before it, Unix time reads close to it, and the two readings are ten years apart. ExifTool decides the same way, by comparing against CreateDate. The make decides only when the creation time is missing or meaningless. This replaces the warning Fix GPS epoch vs Unix epoch mix-up when geotagging CAMM videos #828 added for the same signature.
• The decision uses the median timestamp of the track, so one stray sample cannot flip the whole track. Nothing is dropped.
• The make matches as a substring.
• The native extractor returns type 5 and type 6 points merged in time order. No camera is known to interleave the two types. The GPX sync already reads the video's clock from the first point that carries a timestamp (Sync a GPX to the GPS clock of a timelapse, even one too noisy to publish #849), so a track starting with a type 5 point still syncs.

Writes are unchanged: Unix time for every make.

Verification

• 25 CAMM captures (14 Labpano across PanoX V2, Pilot One and Pilot Era, an Insta360 Pro2, 9 Ricoh Theta X, and a GoPro MAX video processed by mapillary_tools): the parsed points and timestamps are identical to main. The creation time decides on every Labpano capture.
• Building the upload of two Labpano captures the way the uploader does and parsing it back: main reads 2024-01-11 back as 2034-01-15 and 2022-12-03 as 2032-12-07. This branch reads both back identical to the source.
• 15 of the new tests fail on main.
• Unit: 774 passed, 18 skipped, 1 xfailed. Integration: 57 passed. Doctests pass. ruff check, ruff format --check, usort diff and mypy are clean.

Known limitation

For a Labpano source without an mvhd creation time, only the make is left to decide, so our output of it still reads back ten years late. All 14 Labpano captures above have a creation time.