Anchor the GPS clock of a video at the median of its timestamps

[caglarpir]

Problem

_read_video_clock() (#849) anchors the GPS clock of a video at its first timestamp, which can be off the rest:

• The first GPS block of a GoPro timelapse can be stamped 3 s early. The test fixture max-360mode.mp4 has one 1 s early.
• The PanoX V2 can record a stale first fix 2 s old.
• GoPro stamps a placeholder date until it acquires GPS time.

The whole GPX then lands that much early or late.

Changes

The clock is still anchored at the video time of its first timestamp, but at the median of all its timestamps mapped back to that time at the clock's rate.

Verification

The tracks of 17 sample videos exported as GPX and synced back to their videos. Median error:

Video	main	this PR
PanoX V2	2.2 s	0.02 s
GoPro MAX	0.81 s	0.02 s
GoPro MAX	0.63 s	0.02 s
GoPro MAX2	0.40 s	0.001 s
GoPro timelapses	0.002 to 0.20 s	0.011 s or less
Labpano Pilot One	18 s	8 s

No median gets worse by more than 4 ms. A noisy GoPro video whose clock starts on the placeholder date is now synced by its clock, which agrees with the clock of the next clip from the same camera.

test_process_video_geotag_source_with_gpx_outside_video expects the video start 1 s later. Unit: 916 passed, 18 skipped, 1 xfailed. Integration: 69 passed. Doctests, mypy, ruff check, ruff format --check and usort diff are clean.

With #851: two of its tests expect the first-timestamp anchor of max-360mode.mp4, -2.59 s and -2590 ms, which become -3.613 s and -3612 ms.