Fix unreliable small custom seek steps (e.g. 1 ms) on single key press (#12027)

[muaz978]

Fix unreliable small custom seek steps on single key press

Fixes #12027.

Problem

When a custom video seek shortcut is set to a very small value (the reporter used 1 ms on "D" / "A"), a single key press usually does nothing, but holding the key works. It used to work in older 4.x builds.

Root cause is in the relative seek path. MoveVideoPositionMs re-reads vp.Position on every press and adds the delta:

SetVideoPositionSeconds(vp.Position + (ms / 1000.0));

While the player is playing or running in frame mode, the libmpv backend's Position getter returns the live time-pos, which lags an in-flight (async) seek rather than the value just requested. So two quick presses both read the same not-yet-updated base position and each computes base + 1 ms, and the second press is effectively lost. With a tiny step this means single presses "sometimes work, mostly don't", while holding the key (auto-repeat) fires fast enough to accumulate across a frame boundary and appears to work.

(When paused and not in frame mode the backend already caches the last seek target, so that specific case was reliable; playing and frame mode were not.)

Fix

Track the intended position across successive relative seeks so every press moves exactly its delta instead of re-reading a possibly stale position:

• MoveVideoPositionMs accumulates from a tracked target while playback is paused and the player still agrees with that target (within half a second).
• The tracker resyncs to the real player position whenever playback is running or the player diverges by more than half a second (the user played, clicked the waveform, or jumped to a cue).
• SetVideoPositionSeconds, the shared choke point for every position change, clears the tracker, and MoveVideoPositionMs re-arms it right after, so only chained relative steps accumulate.

Behaviour for the normal larger steps (500 ms, 1 s, etc.) is unchanged; they already exceeded a frame, and they still resync correctly.

Files

• src/ui/Features/Main/MainViewModel.cs

Note on sub-frame steps

A step well below one frame (1 ms versus roughly 33 to 40 ms per frame) still cannot change the displayed video frame on a single press, but the timecode and waveform cursor now advance by exactly the configured amount each press, which is what fine subtitle timing relies on.