tbV2: preserve recoverable bytes on incomplete-chunk re-admit

When CopyChunkUntrusted re-admits a previously-evicted incomplete chunk,
it uses last_chunk_consumed.payload_size as the "already delivered to
consumer" cursor to skip on the resubmitted payload. EraseCurrentChunk
populated that field with the chunk's total payload at eviction time,
which conflates two very different things:

  - kReadMode: every byte was delivered by reads -> total == delivered.
  - kEraseMode: only the prefix that was drained *before* the wrap pass
    started was actually delivered; the suffix was just overwritten.

The result was that on re-admit the buffer skipped both the
already-read prefix *and* the overwritten suffix, dropping bytes that
the producer's resubmission explicitly carried. This shows up in field
traces (RING_BUFFER + slow file_write_period_ms) as a 1-2 packet
data_loss event with chunks_overwritten=1, bytes_overwritten=4096.

Fix:
  - ConsumedChunkInfo::payload_size -> payload_consumed_by_reads. The
    field name now matches what the re-admit path actually wants.
  - ChunkSeqReader snapshots iter_->payload_avail when it takes
    ownership of each chunk (ctor + NextChunkInSequence). At
    EraseCurrentChunk time the caller derives bytes-delivered as
    payload_size in kReadMode and (payload_size - snapshot) in
    kEraseMode, then passes it down.
  - The re-admit branch in CopyChunkUntrusted now clears seq.data_loss
    when it accepts the recovery. The flag was set by DeleteNextChunksFor
    during the eviction; since the bytes that tripped it are about to be
    replayed from the producer's resubmission the signal is stale. If a
    later eviction on the same sequence (e.g. the DeleteNextChunksFor
    making room for the re-admitted chunk itself) loses real data, that
    path re-sets data_loss.

Test RescrapeAfterEviction_NoReadsBeforeWrap (added in the preceding
commit) flipped from FAIL to PASS with this change.