[#4801] Keep the work package's stored token monotonic from the first store of a claim

[schananas]

Fixes #4801
Fixes #4836

What changed

Two parts, and the first cannot ship without the second.

1. Seed the work package's stored token from the claim (#4801)

lastStoredToken had no initialiser while lastDeliveredToken and lastConsumedToken were both seeded from builder.initialToken. The monotonicity guard is written lastStoredToken != null && ..., so it was skipped on the first store of every claim cycle, per segment. A progress strategy offering a low position at that moment durably rewound the segment with no warning, and the whole segment was redelivered on the next claim.

2. Make coversWhenUnwrapped null-tolerant (#4836)

WrappedToken.unwrapUpperBound returns null for a null-current ReplayToken and for a half-empty MergedTrackingToken, and the helper dereferenced it. GlobalSequenceTrackingToken.covers(null) returns true, so this hid; GapAwareTrackingToken.covers(null) throws, and the JPA engine's firstToken() returns a GapAwareTrackingToken that Spring Boot wires by default.

TrackingToken unwrappedReference = WrappedToken.unwrapUpperBound(reference);
if (unwrappedReference == null) {
    return true;
}
TrackingToken unwrappedCandidate = WrappedToken.unwrapUpperBound(candidate);
return unwrappedCandidate != null && unwrappedCandidate.covers(unwrappedReference);

A null reference means no raw stream position is recorded, so there is nothing to regress from and accepting the store is behaviour-preserving -- pre-seed, a null lastStoredToken skipped the guard and the store went through anyway. Rejecting would wedge a just-reset segment for ever. The candidate side is guarded too: an unguarded version NPEs when the candidate unwraps to null, and returning false matches the method's own promise for an incomparable token.

There is exactly one production call site, WorkPackage:518, so the reasoning only has to hold there.

The second defect is pre-existing, not introduced here

On pure main the second store of the idle-beat sequence already throws IllegalArgumentException: Incompatible token type provided: null: upkeepIfThresholdIsMet sees Objects.equals(replayToken, null) as false, drives onBatchCommit and persists the null-current ReplayToken, and the guard is skipped because lastStoredToken is null, so the empty token becomes the reference. The seed only moves that empty reference from store #1 to construction; the helper fix closes both.

Tests

With both fixes: 258 testcases, 0 failures. Each half is independently load-bearing: removing the helper fix gives 3 errors (the WorkPackage case and both TrackingTokenUtils cases), removing the seed gives exactly 1 failure, persistProgressIgnoresATokenBehindTheClaimedTokenOnTheFirstStoreOfAClaim.

Across WorkPackageTest (35), TrackingTokenUtilsTest (14), ReplayTokenTest (31), MergedTrackingTokenTest (20), GapAwareTrackingTokenTest (33), CoordinatorTest (22), PooledStreamingEventProcessorTest (70), TokenStoringProgressStrategyTest (5), ReplayTokenWrappingComplexTokenTest (28).

Why CI could not have caught this

Every existing test touching the default replay initial token uses GlobalSequenceTrackingToken, the one type that tolerates covers(null). Nothing in the tree pairs a pooled processor with a GapAwareTrackingToken, so the full 4253-test messaging suite stays green on the broken code. The new WorkPackageTest case uses ReplayToken(GapAwareTrackingToken(5), null) to close that blind spot.

For the reviewer

The guard in storeIfAdvanced and the idle-upkeep gate are otherwise unchanged; they simply now have a non-null reference on the first store after a claim.

A second intended effect: the idle gate Objects.equals(lastConsumedToken, lastStoredToken) never held on a freshly claimed idle segment, contradicting its own Javadoc that an idle segment never drives a strategy with an unchanged position. Seeding makes it hold, so a freshly claimed idle segment stops invoking onBatchCommit until something is consumed. No strategy can be starved: hasPendingWork() routes an idle segment through a commit cycle before the upkeep gate. Claim extension is unaffected.

Left alone deliberately: WrappedToken.unwrapUpperBound is declared non-null in a @NullMarked package but returns null for these shapes. Marking it @Nullable is the honest fix and cascades to every caller in the tree; ReplayToken:129 already null-checks its result, so the precedent for handling it in place exists.