tbV2: fix data loss on re-admit of scraped+evicted chunks

On RING_BUFFER buffers with a slow consumer (e.g. write_into_file with a
multi-minute file_write_period_ms), a scraped chunk can be evicted by the
wrap before any reader has touched it. When the producer later commits the
same chunk_id with chunk_complete=true and more data, CopyChunkUntrusted
takes the re-admit branch.

The re-admit was using last_chunk_consumed.payload_size as the "bytes the
consumer already saw" cursor and skipping them on the resubmitted chunk.
But EraseCurrentChunk wrote that field to the chunk's total payload
regardless of how the chunk left the buffer, so any bytes that were
overwritten without ever being read got skipped on re-admit too. The
producer resubmitted them and the buffer threw them away anyway.

Fix:

ChunkSeqReader tracks bytes_overwritten_in_chunk_, reset on every chunk
transition and incremented in ConsumeFragment when mode_ == kEraseMode.
EraseCurrentChunk records payload_read = payload_size - bytes_overwritten
on last_chunk_consumed. The field was previously called payload_size; it
is now payload_read to match what it actually stores. CopyChunkUntrusted's
re-admit branch uses payload_read for both the acceptance check and the
skip count.

A second source of loss is detected even when the chunk_ids stay
contiguous: eviction advances last_chunk_consumed.chunk_id, so a chunk
overwritten with unread packets would look like a clean successor. We
record had_unread_on_evict on the erased chunk and turn it into a data
loss in ChunkSeqReader's ctor, unless the same chunk_id is re-admitted.

ConsumeFragment only attributes bytes to bytes_overwritten_in_chunk_ for
iter_, the chunk being erased. Fragment reassembly also consumes
continuation fragments out of later chunks, and charging those to the
current chunk would overshoot its payload_size (tripping the DCHECK in
EraseCurrentChunk and underflowing payload_read in release builds).