v0.7.1 — an export renders only the fragment frames the edit uses

This release came out of a real overnight export: a 26-minute film whose
progress sat at 50 % after eight hours and then stopped moving. The export was
working — it was just doing about seventeen times more work than the edit
needed. Nothing in the interface changes.

Fragments render only the frames the edit shows

A long film is often built as windows of one continuous composition: every
scene is a fragment that contains the whole timeline of the film, and its clip
starts at the in-point where that scene belongs. The export used to render each
such fragment from frame 0 to its end, so every scene cost the whole film up to
that scene, each one slower than the one before. On that project it was 1.6
million frames for the 93 thousand the edit actually shows — roughly 35 hours
of fragment rendering.

Now the export works out which stretch of each composition its clips show and
renders only that, plus half a second either side for the motion-blur shutter,
frame blending and rounding (remotion render --frames=f0-f1). Clips of one
fragment that are close together in the composition share one file; clips more
than 10 s apart get files of their own.

• The picture is identical. Frame numbers are absolute, so a fragment draws
  exactly the frame it drew in a full render; the file simply begins later, and
  the clip's in-point is moved back by the same amount.
• Looping clips still loop where they did. A clip that runs past the end of
  its composition gets everything from its in-point to the last frame, so the
  loop span is unchanged.
• Existing caches stay valid. A full render already on disk contains every
  range and is always used first, so nothing finished in an earlier export is
  rendered again. Partial renders are cached under their own names
  (…-r<first>-<last>) and show up in the storage panel with their fragment.

On that film this leaves about 50 thousand frames still to render instead of
1.25 million.

Fixed

• The first frame of a clip could come from a second later. In the export
  decoder, mp4box keeps the batch of samples it was collecting across a seek
  and delivers it first afterwards. On light files — flat graphics, small
  renders, typical fragment output — the very first seek always met that
  leftover. Either the decoder started on a keyframe from later in the file
  (a single wrong frame at the start of the clip, visible as a flash on the
  cut), or it started on a non-key frame, failed with «A key frame is
  required», and the whole clip silently fell back to element seeks at
  around 0.2 s per frame. The seek now drops that batch.
• A looping fragment clip held its last frame before wrapping. Remotion's
  silent audio track runs up to ~60 ms past the last frame, and the asset's
  duration was taken from the container, so a loop held the final frame for
  3–4 frames at 60 fps. The duration is now the picture's own (frames ÷ fps).

Verification

• New suite e2e52: a 15-second fragment at 60 fps whose every frame shows
  its own number in pixels, four clips of it (a window, a far one, one looping
  past the end, one at ×2). Every frame of the export is decoded and compared
  with the frame the fragment should show — once with partial renders and once
  with a full render on disk — plus the export decoder's first frame and
  backward jumps on a partial file. 150 of 150 frames match; the suite fails
  with either fix taken out.
• The export, decoder and fragment suites (e2e17, 19, 21, 24, 25, 30, 32, 33,
  35, 44, 45, 46, 47, 49) pass unchanged; typecheck and build are clean.