perfetto: add test for SMB scraping in TraceBufferV2 (#5122)

In write_into_file traces with long flush periods (e.g. 1h),
SMB scraping can re-introduce chunks whose index entries were
already evicted by ring buffer wraparound. When this happens,
CopyChunkUntrusted treats the chunk as entirely new (since
index_.find() misses), resetting num_fragments_read to 0.
ReadNextTracePacket then re-reads all fragments, producing
duplicate packets that cause out-of-order errors in the trace
sorter (e.g. "trace_sorter.cc: out of order events").

The root cause is that DeleteNextChunksFor removes index entries
(and their read progress) when the ring buffer wraps, but SMB
scraping doesn't change the producer's shared memory state. So
the next scrape finds the same chunk, and without the index entry,
there's no record that fragments were already consumed.

We don't want to fix this in TraceBufferV1 because its quite risky
*and* we're anyway trying to move to v2 due to other, unfixable bugs
with v1.

Just add a regression test to V2 to ensure that this bug doesn't
reappear.