Bug description
When a job execution fails multiple times (i.e., more than once), resuming the job does not start from the last failed execution. Instead, it restarts from the initial execution attempt, causing AbstractItemCountingItemStreamItemReader to rely on an incorrect item count.

Environment
Spring batch 5.2.2
JVM 21
Kotlin 2.1.21

Steps to reproduce

1. Run a job and let it fail on the first execution.
2. Resume the job – it correctly continues from the last processed item.
3. Let the job fail again on this resumed execution.
4. Resume the job again – it unexpectedly starts from the same index from point 2, not from the point where the second execution failed.

Expected behavior
The job should resume from the last failed execution, maintaining the correct item count, rather than restarting from the initial execution.

I suspect the issue lies in the part of the code where stepExecutions are sorted in ascending order and the minimum is taken. This likely causes the job to resume from the earliest execution instead of the most recent one.