Validate stream listpack live and deleted counts on load

[roshkhatri]

Problem

streamValidateListpackIntegrity() checked only that live + deleted matched the number of records it walked, never the split between them. A payload declaring live=1, deleted=1 for two records that are both live validates cleanly, because the traversal consumes two records either way and lands exactly on the terminator.

XDEL then trusts the cached live count to decide when a node is exhausted:

aux = lpGetInteger(p);          /* the DECLARED live count */
if (aux == 1) {
    lpFree(lp);                                  /* frees the whole node */
    raxRemove(si->stream->rax, si->ri.key, si->ri.key_len, NULL);
}
...
si->stream->length--;           /* decremented once, for one entry */

Deleting one entry frees the node holding the other, and s->length comes from a separate RDB field that is only decremented once, leaving the key permanently self-contradictory:

RESTORE      +OK
XLEN         2
XDEL 1-0     1
XLEN         1          <- claims one entry
XRANGE - +   (empty)    <- both are gone

That state propagates to replicas, the AOF and every subsequent RDB save. streamTrim() has the same exposure from the other direction: lpReplaceInteger(lp, &p, entries - deleted_from_lp) writes a negative live count when the header understates. Reachable by anything that supplies a payload: RESTORE, RDB load, replication.

This PR

Counts the STREAM_ITEM_FLAG_DELETED flag while validating and rejects the payload if either counter disagrees with the records actually present. Also tracks entries consumed so the declared field and record counts are bounded against what the listpack holds.

Validation stays entirely at ingestion, per valkey-io#3721. No format or protocol change, and valid data behaves exactly as before.

Testing

Five gtest cases against the validator. Three fail on the unpatched validator: TestRejectsUnderstatedLiveCount, TestRejectsOverstatedLiveCount, TestRejectsAllRecordsDeletedWithLiveHeader. The two Accepts* cases are controls against over-rejection.

One integration test in corrupt-dump.tcl built from a valid two-entry control by changing the primary entry count from 2 to 1 and its deleted count from 0 to 1, then recomputing the CRC64. Verified both ways: base accepts it and reproduces the data loss, this rejects it. corrupt-dump, stream, stream-cgroups: 230 passed.

Scope

The second commit reduces this PR per review feedback. The access-time detection layer is reverted: the tri-state stream iterator, the listpack random-helper return codes and the per-entry re-validation. valkey-io#3721 made dump payload validation unconditional and already rejects a listpack whose header count disagrees with its contents, so those shapes never reach the read path, and re-validating each entry during iteration tripled the cost of stream reads.

Net effect is 14 files / +597−124 down to 3 files / +147−6. Gone with it: the XRANGE and XREVRANGE partial-return behavior, the EIO contract change on VM_StreamIteratorNextID(), and every new corruption panic. The tests for the reverted behavior are dropped too; the stream field count case was already covered upstream, and the listpack header count case belongs with the check it guards.