Handle the 32-bit Elasticsearch missing-sort sentinel

What does this MR do and why?

Elasticsearch substitutes a sentinel for a missing value when sorting, chosen by the field's numeric comparator rather than its declared range. Elasticsearch 8.19 and 9.1 moved byte, short and integer onto the int comparator, so those fields now emit Integer.MAX_VALUE where they used to emit Long.MAX_VALUE.

Relation#cursor_for only recognised the long-width sentinels, so the sentinel reached Pagination unconverted, its non-null filter branch matched nothing, and the cursor stopped advancing. Sorting work items by a nullable weight or health_status re-serves the same page forever.

Only the sort property is converted now. The tie breaker is a non-null long id that legitimately reaches these magnitudes, and nil-ing it makes Pagination#paginate emit no pagination filter at all, which would strand the cursor rather than repair it.

NOTE:

The one case which we should be weary about is when the sort property is a LONG type and it has a genuine INT_MAX value. For that particular case this approach is straight up wrong. But that is only for 1 single record across the whole table in the DB, so I think that is an acceptable risk. Any better approach would require us to actually type check the field and check for max values.

References

Resolves #627210 (closed)

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.