Prevent step execution leakage between flow job executions

[jjj-n]

When no transition matches a step's exit status, SimpleFlow.nextState() throws outside the block that closes the executor. The static JobFlowExecutor holder can then expose the failed step to a subsequent job execution on the same thread, which may mark it ABANDONED and prevent restart.

This change closes the executor when transition lookup fails and scopes the thread-local holder to each executor. Thread isolation within an executor is preserved for parallel flows.

Four JDBC-backed regression tests cover preserving another job's persisted step status and version, restarting after an unmatched transition, exceptional cleanup, and isolation between executors. The new tests fail against the original implementation and pass with this change.

Fixes #5514

Validation on Windows with JDK 25:

• Flow-related tests: 64 tests, 0 failures/errors, 4 skipped.
• Core unit suite: 832 tests, 0 failures/errors, 47 skipped.
• Selected restart, partition, nested/async scope, and H2/HSQL repository integration tests: 15 tests, all passing.
• The unchanged issue reporter's MCVE, using the locally built 6.1.0-SNAPSHOT, re-runs the failed step, preserves the first job's FAILED status after another job runs, and no longer produces the stale-copy optimistic locking failure. The catch-all control still behaves correctly.

The full mvn install attempt stopped at two failures in the unchanged infrastructure module: AbstractFileItemWriterTests.testFailedFileDeletionThrowsException and StaxEventItemWriterTests.testFailedFileDeletionThrowsException. Both stub File.delete(), while the implementations call Files.delete(). A follow-up all-module test run with -Dmaven.test.failure.ignore=true reported only these same two failures; the core, test-support, and integration modules had no failures. The full integration/functional suite has not passed locally.