Keep a timelapse's clock rate when the GPX starts with the video

[caglarpir]

Problem

--interpolation_use_gpx_start_time skips reading the video's GPS clock, and with it the clock's rate (#849), so a timelapse gets its GPX laid out at 1x. Distance sampling a 5 s, 30x GoPro MAX timelapse picks 5 frames along the first 12 m of its 1.4 km route.

Changes

• In that mode the clock is still read, and placed at the start of the GPX, so that only its rate is used. A video that is not a timelapse has a rate of 1 and is placed as before.
• _check_coverage() raises only when the clock a track was placed by says that the track misses the video. A clock placed at the start of the GPX says nothing of the kind, so in this mode a miss still only warns, as it did before.

Verification

• The 30x and 15x timelapses: 148 and 81 frames along the whole route, the same as without the option. Main gives 5 and 8.
• GPX sync in this mode across 20 sample videos: only the 7 timelapses that Sync a GPX to the GPS clock of a timelapse, even one too noisy to publish #849 detects change, and each GPX now spans its video (for example 157 s becomes 5.2 s). Normal-speed videos, and noisy GPS with placeholder dates, are identical to main.
• Unit: 915 passed, 18 skipped, 1 xfailed. Integration: 69 passed. Doctests, mypy, ruff check, ruff format --check and usort diff are clean.

With #851, which drops offset_time from VideoSyncOption: test_gpx_start_time_only_warns_of_a_miss then passes interpolation=InterpolationOption(offset_time=3600).