POP revive checkpoints are ordered by reviveOffset before mergeAndRevive advances through the pending checkpoints. The previous comparator subtracted two long offsets and cast the result to int, so large offset gaps could reverse the intended ordering.

Use Comparator.comparingLong to preserve the full long ordering and add a regression test covering offsets separated by more than Integer.MAX_VALUE.

Constraint: reviveOffset is a long queue offset and can exceed int comparison range

Rejected: Keep subtraction with a wider cast | Comparator APIs express the ordering directly and avoid overflow

Confidence: high

Scope-risk: narrow

Directive: Do not compare long queue offsets by subtraction in POP revive ordering

Tested: mvn -pl broker -Dtest=PopReviveServiceTest test -Dspotbugs.skip=true -Dcheckstyle.skip=true

Tested: git diff --check

PopReviveService keeps inflight checkpoints in a TreeMap<PopCheckPoint, ...>
(inflightReviveRequestMap), which orders keys via PopCheckPoint.compareTo. That
comparator subtracted two long startOffsets and cast the result to int, the same
overflow pattern already fixed for the reviveOffset sort in the prior commit. With
large offset gaps the TreeMap could misorder keys and corrupt the revive ordering.

Use Long.compare to preserve the full long ordering and add a regression test
covering startOffsets separated by more than Integer.MAX_VALUE, including TreeMap
ordering which exercises the actual PopReviveService usage.

Constraint: startOffset is a long queue offset and can exceed int comparison range

Rejected: Keep subtraction with a wider cast | Long.compare expresses the ordering directly and avoids overflow

Confidence: high

Scope-risk: narrow

Directive: Do not compare long queue offsets by subtraction in POP checkpoint ordering

Tested: mvn -pl store -Dtest=PopCheckPointTest test

Tested: git diff --check

Co-Authored-By: Claude <noreply@anthropic.com>