fix(data): apply --start-time-sec to COLMAP camera frame timestamps

[janickm]

Description

ColmapCamera.timestamps_us was declared as a @property that also took a
start_time_sec parameter. A property cannot receive arguments, so every
access used the signature default of 0.0 and the configured offset never
reached the camera frames.

The offset did reach the declared sequence interval
(colmap/converter.py:256-257) and the SfM point cloud's reference timestamp
(:351). So with a non-zero --start-time-sec the sequence interval began at
the offset while frames stayed at t=0. Since the writer asserts frame
containment rather than clamping, conversion fails outright:

--start-time-sec 10, 4 images
frames:   [0, 1e6, 2e6, 3e6]          <- ignores the offset
interval: [10e6, 14e6)
=> "Frame start timestamp must be contained in the sequence time range"

Carries start_time_sec on ColmapCamera and reads it from self. Both
construction sites pass it through.

Found while fact-checking the ncore skill in #181 against the source.

Testing

Adds converter_test.py; the COLMAP package had no test target before. It is
data-free and runs in CI, following the argoverse2:pytest_utils precedent.

Verified as a real regression guard: reverting the property to the old form
makes it fail, and restoring the fix makes it pass.

bazel test //tools/data_converter/colmap:pytest_converter_3_11   # 4 passed
bazel test //tools/...                                           # 6/6 pass
bazel run //:format.check                                        # clean

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Checklist

• I have read the Contributing Guidelines
• My commits follow Conventional Commits format
• My commits are GPG-signed
• I have added tests that prove my fix is effective or my feature works
• New and existing tests pass locally (bazel test //tools/...)
• Code is formatted (bazel run //:format)
• I have updated documentation as needed
• My changes include SPDX license headers on all new files