Recording that ends on a still screen doubles the last frame's duration and fails the duration check #46

When a screen recording ends on a still screen, the encoder holds the last frame about twice as long as it was on screen, and the runner's own duration check then fails the take.

Seen in: PodNotes' docs video recording (docs/scripts/videos.mjs, held docs PR chhoumann/PodNotes#458), recording through the instance's DevTools screencast on Linux with obsidian-e2e 0.13.

Repro: record a take whose last second or more has no screen change, then stop. The output duration exceeds the recorded wall-clock time by roughly the length of the final still stretch, and the duration check rejects it.

Likely cause: the screencast only emits frames on change, and the encoder gives the last received frame a duration based on the gap to the stop time, counted twice (or the final frame's timestamp isn't clamped to the stop time).

Workaround used: an invisible 1-pixel animation keeps frames flowing until the stop. It works, but the runner should handle a still ending: clamp the last frame's duration to the stop timestamp.