Partitioned Step execution not saved properly in production job with Spring Batch 5.2.x (works in 5.1.3)

Bug description

This issue is the same as discussion #4683, but with additional details and version isolation. Currently I am on spring boot 3.5.6 and the issue occurs only with Spring Batch 5.2.x (e.g., 5.2.3). When using Spring Batch 5.1.3 (explicitly set via <spring-batch.version> with Spring Boot 3.5.6), the problem does not occur. By default, Spring Boot 3.5.6 pulled Spring Batch 5.2.3, which triggers the failure. This confirms the issue is related to changes in Spring Batch after 5.1.3.

Additional debugging details

Through debugging, I found that the class org.springframework.batch.core.repository.dao.JdbcStepExecutionDao fails to properly save a particular step to the database which was being routed through the method public void saveStepExecutions(final Collection<StepExecution> stepExecutions).
The count variable on line 284 of JdbcStepExecutionDao is set to 0 for the faulty step, and after several more method calls, the following error occurs:

org.springframework.dao.EmptyResultDataAccessException: Incorrect result size: expected 1, actual 0

The faulty step eventually gets saved with version 0, but it is expected to be 3 (as seen in a recreated scenario for Spring Batch 5.1.3).
Other steps that were saved via public void saveStepExecution(StepExecution stepExecution) worked fine.

Database and environment

• Database: PostgreSQL 42.7.7
• Backend: Spring Boot 3.5.6

Environment

• Spring Batch: 5.2.x (confirmed failing)
• Spring Batch: 5.1.3 (confirmed working)
• Spring Boot: 3.5.6

Expected behavior
Job should not fail with EmptyResultDataAccessException when updating step status; should behave as in 5.1.3.

Please let me know if any further specific information is required.

Start with org.springframework.batch.core.repository.dao.JdbcStepExecutionDao, especially saveStepExecutions(Collection) and the reported count handling. Reproduce the partitioned job with Spring Batch 5.2.x and PostgreSQL, then compare it with 5.1.3. Done means the step is saved with the expected version and the job no longer raises EmptyResultDataAccessException.