AppendEntriesPrevLogIndexOutOfRange

RaftEngine.batchRefusal bound 1 (#1832): an AppendEntries whose prevLogIndex is outside 0 .. Long.MAX_VALUE - entries.size - 1 — a probe point below the log origin, or one so high that computing the batch's expected indices would overflow.

One gate for a two-clause bound, deliberately — and the same choice is made at AppendEntriesEntryTermOutOfRange, InstallSnapshotIndexOutOfRange and InstallSnapshotTermOutOfRange. Each of those is a range test written x < lo || x > hi, whose two arms are mutually exclusive on any one frame: no prevLogIndex is both negative and above Long.MAX_VALUE - entries.size - 1. Mutual exclusivity is the precise reason a shared gate is safe here and not merely cheap — the shadowing this enum exists to undo needs two guards refusing the same frame, and arms that cannot co-fire can never stand in for one another. Delete either arm and its own probe is admitted outright, so a suite carrying one probe per arm still reddens; AppendEntriesBatchValidationTest and InstallSnapshotMetaValidationTest carry exactly that (#2022, #2031). What the shared gate does give up is diagnostic resolution: a trace reader is told the probe index was out of range, not which end. Split the value in two if that ever matters operationally — the arms are already separate expressions.

Currently silent apart from a debug { }, which is why attribution is worth more here than a state-effect assertion: #2031's receipt is that deleting the overflow arm leaves the frame processed and answered, rejected a screen later by the §5.3 consistency check with AppendEntriesRejected(conflictIndex = 8) and never reaching the log. A log-based assertion at that site is not ambiguous, it is blind.