Fix reindex shifting ottrk frame numbers to the first detection

[Sebastian-Gerken]

Bug

FinishedTracksExporter.reindex() rebases detection frame numbers using the minimum frame number that has a detection:

min_frame_no = min(det[FRAME] for det in det_dicts)
...
{**det, **{FRAME: det[FRAME] - min_frame_no + 1}}

If the first detection of a video occurs after frame 1, every frame number in the written .ottrk is shifted towards 1, while occurrence keeps correct wall clock time — frame and occurrence then disagree by exactly the time of the file's first detection.

Impact

• Any tracked video whose first (surviving) detection is not in frame 1 gets inconsistent frame numbers. On low-traffic recordings (e.g. night-time 15-min segments) we observed shifts of 10 s up to several minutes.
• In OTAnalytics the track overlay renders too early relative to the video: the first track appears at the very start of the video regardless of when it actually occurred.
• The number_of_frames metadata no longer matches the maximum written frame number.

Fix

Rebase by the chunk's first frame number (chunk frames include frames without detections), so written frame numbers always match the source video's frame numbering:

• new abstract get_first_frame_no(container) on FinishedTracksExporter
• FinishedChunkTrackExporter implements it as min(frame.no for frame in container.frames)
• reindex(det_dicts, first_frame_no) uses it instead of the per-detection minimum

Tests

• New tests/track/test_track_exporter.py:
  • a chunk whose first frame has no detections must keep video frame numbers (fails on main with [1, 2] != [2, 3], passes with the fix)
  • a chunk without any detections still writes an empty detection list (guards the OP#9383 behaviour)
• tests/track suite green; mypy, black, isort, flake8 clean.

🤖 Generated with Claude Code