fix(video): pin output framerate on rendered analyzer clips

[Abdullah-Builds]

Fix analyzer clip output framerate

Fixes #52

What

render_timeline_clip() never set an explicit output frame rate on the final ffmpeg encode, so the encoder fell back to a default 25fps and duplicated frames to preserve real duration — every analyzer clip was silently encoded at ~25fps instead of the requested fps (default 15), with ~40% duplicate frames.

Why it matters

This function's one job is to keep a frame index mappable back to a real recording timestamp (start_time + frame_offset). UnifiedMobileController.render_timeline_clip calls it on the production path for every analyzer clip the agent renders, so the framerate drift was live in every such clip, not just this test fixture.

Fix

Add -r {fps} to the output stage of the ffmpeg command so the encoder has an explicit target framerate instead of guessing:

             "-filter_complex", ";".join(filter_parts),
             "-map", "[outv]",
+            "-r", str(fps),
             "-c:v", "libx264",

Testing

tests/unit/test_unified_controller_video.py::test_analyzer_clip_keeps_timeline_time_across_restart_gap was failing on main (assert 77 <= 47); now passes — frame count drops from 77 → 46, inside the expected 43–47 range.
Full file: uv run pytest tests/unit/test_unified_controller_video.py -q → 22 passed.
ruff format --check, ruff check, pyright --project pyright-core.json clean on the changed file.
Reproduced independently of pytest (raw ffmpeg command + cv2.VideoCapture frame count) to confirm this isn't a test-fixture artifact — the ffmpeg log shows the fallback explicitly: frame=77 ... time=00:00:03.00 ... dup=31 drop=0.

Scope

One-line change, single file (artemis/utils/video.py), no behavior change to segment planning or gap handling — only the output encode step.