tbV2: relocate fully-read scraped chunks instead of rewriting them (#6767)

Fixes a data-loss race seen in 24h field traces with sporadic writers.
Fingerprint: orphan_continuation = overwrite = sequence_packet_loss = 1
on the
buffer, one packet with previous_packet_dropped = 73.

The race:
- A flush scrapes a writer's half-full chunk; the incomplete copy is
pinned in
  the buffer and read over time.
- Hours later the writer commits the chunk. The recommit rewrote it in
place,
  at the now-stale offset, with the write cursor almost a lap ahead: the
  never-read fragments could be overwritten before the next read pass.
- If the chunk ends with kFragBegin, that eviction destroys the begin
fragment
  and its continuation later reads back as an orphan.

The fix:
- If the scraped copy is fully consumed and the final commit brings new
fragments, erase the stale copy and relocate the chunk to the write
cursor,
  reusing the re-admit path for evicted chunks (#5372).
- previously_consumed_payload skips what was already read, so nothing is
  duplicated; ChunkIDs stay consecutive, so no read gap.
- Rescrapes, partially-consumed and out-of-order recommits keep the
in-place
rewrite, as do kDiscard buffers (they never lap, and the write path
could hit
  DiscardWrite() and drop the fragments being recovered).

New chunks_relocated stat (BufferStats field 20) counts these, mirroring
chunks_rewritten. Field 20 was never assigned in BufferStats: the CL
below
added bytes_discarded_per_buffer = 20 to FilterStats but bumped the
"Next id"
above BufferStats, leaving a phantom hole. https://r.android.com/2882818

Four new tests cover the race itself, the rescrape / unread-payload /
kDiscard
exclusions, and the case where the continuation chunk is already
buffered.

Bug: 518755701.