Dropping a new clip whose in-point landed in empty track space (the
stored-range model allows holes between blocks; the C++ layout is
contiguous) left the overlapped clip untouched AND inserted the new clip
before it in track order, so it slid UNDER the clip it covered. Starting
on a clip already overwrote correctly, so the behavior depended on where
the in-point happened to fall.
TrackRippleRemoveAreaCommand::prepare now handles the hole case (no
block spans the range start): nothing is trimmed on the left, the
insertion anchor is the last block ending at/before the range, and the
shared trailing scan removes/head-trims the blocks the range covers.
Regression tests: domain_test (command level) and graphops (the app's
place_footage_clip path).
Mike-Solar
21dbde8435