fix(lerobot): stop flooring a fractional source fps

[chiruu12]

Fixes #458

meta/info.json is allowed a fractional fps and _parse_dataset_information stores it as
one, but the single call site floored it with int(source_archive.fps). A corpus
declaring 29.97 was converted as if it were 29.

The keyframe interval is the primary half. _transcode_mp4_to_h264 computes
round(gop_seconds * frames_per_second), which is 30 at the declared rate and 29 at the
floored one, so the file carried a 29 frame GOP while provenance/v1 stamped
gop_seconds as 1. That field is recorded as what was actually used and nothing checks
it, which is what #376 is open about. This was one of the ways it could already be false.

The time axis is the visible half. Log times are frame_index * 1e9 / frames_per_second,
so the whole episode stretches:

frame     1: source    0.0334s   written    0.0345s   drift +0.0011s
frame    30: source    1.0010s   written    1.0345s   drift +0.0335s
frame   900: source   30.0300s   written   31.0345s   drift +1.0045s
frame  5400: source  180.1802s   written  186.2069s   drift +6.0267s

Both consumers already took a float, so the fix is the int() at the call site and the
annotation that forced it.

CONVERTER_VERSION moves to v8, and the reason is resume rather than bytes.
_episode_identity_matches compares dataset, revision, episode index, camera keys,
converter version and gop_seconds. It never looks at fps, so an episode delivered before
this fix with the stretched time axis still matches on every field and the resume path
would hand it back as completed work. The bump is what makes those episodes fail identity
and be re-converted. This differs from the bumps in #390 and #403: those moved every
episode's content id, this one changes bytes only for fractional-fps sources, and an
integer-fps corpus produces identical output either way.

Tests, in the order they were asked for:

• the declared fps reaches conversion untruncated
• the log times come from the declared rate, with the floored value asserted absent
• the rate the transcoder receives yields a keyframe interval of 30 rather than 29
• an episode stamped with the previous converter version is refused by reuse

All four fail on the commit before the fix. The corpus helper now takes an fps so the
end-to-end import runs at 29.97 rather than the integer 30 every existing fixture uses,
which is why this survived: nine fixtures, all at 30, and int(30.0) is 30.

tests/test_lerobot_converter.py tests/test_lerobot_metadata_refusals.py tests/test_lerobot_export.py: 107 passed. ruff check, ruff format --check and
ty check are clean.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[kstonekuan]

LGTM, merging.

Both halves are held separately. Dropping the truncation fixes new conversions; the version bump is what stops resume handing back episodes already written with a stretched time axis.