fix(video): only enable videocomposer wraparound for cues that repeat (869fa89uh)

[ibiltari]

Problem

At the end of a play-once video cue the first frame of the video is shown again for a frame or two before the layer goes black. Reported at Medina del Campo sala1 (ClickUp 869fa89uh).

Cause

loop_videoCue sent /videocomposer/layer/<id>/loop 1 for every video cue, including loop=1. With wraparound on, the videocomposer wraps to frame 0 at end of file instead of holding the last frame.

The videocomposer runs its display latency (33 ms) ahead of MTC, and the engine ends the body on a 25 fps frame boundary and sends /visible 0 a few ms later. So whenever the real file is less than about 40 ms longer than the engine's body length, the layer reaches end of file first and wraps.

Change

• Send /loop 1 only when cue.loop != 1.
• On the last pass of a counted loop, send /loop 0 right after the new offset, so the end of that pass holds the last frame like a play-once cue.
• Infinite loops are unchanged (run_videoCue still enables wraparound early for them).

Testing

• New tests/test_loop_video_wraparound.py: play-once sends no /loop; a counted loop sends /loop 1 then /loop 0 after its last offset; an infinite loop never sends /loop 0. Run on test2 with tests/test_loop_rebase.py and tests/test_loop_fade_cue.py: 14 passed. Against rc_1's loop_cue.py the new file fails 2 of 3.
• test2 rig, play-once 10 s clip: with the change no /loop 1 is sent and the cue ends and hides normally.
• Not exercised on a rig: the counted-loop (loop > 1) path. The full suite was not run.

Not in this PR

Half the durations in the sala1 project are stored short by the old zero-padding bug (cuems-editor-repair-durations not yet run there); those cues are cut early instead. Separate issue.