fix: timeRange trimming drops the first timeRange.start of the selection.

[madsodgaard]

startSession(atSourceTime: timeRange.start) already makes AVAssetWriter rebase
source time to movie time, but video frames are also appended at
PTS - timeRange.start. That applies the offset twice, so frames before
timeRange.start resolve to a negative movie time and the writer discards them —
append still returns true, so nothing surfaces as an error. Audio is appended
unmodified and keeps the full range.

Trimming an 18s clip to 3s–18s gave me a 15s file with a 12s video track and a
15s audio track: playback starts ~3s into the selection, and the final frame is
frozen for the remaining 3s.

Appending with the original presentation timestamp fixes both append paths and
matches what the audio path already does. Progress reporting still uses the
range-relative time, so that behaviour is unchanged.

One thing worth knowing: this dates back to the initial commit, but it used to be
masked. CVPixelBufferPoolCreatePixelBuffer fails with
kCVReturnInvalidPixelFormat (the pool attributes ask for
kCVPixelFormatType_32RGBA), so handled stayed false and every frame fell
through to the plain input.append(sampleBuffer), which got the timing right by
accident. #39's black-frame fix skips that allocation when there's no render
handler, which is what made the bug reachable in 1.0.1.