fix: single statement lock-and-fetch unresolved task from first batch…

[strelchm]

Added unpicking of unresolved tasks in single‑statement LOCK_AND_FETCH mode

When a task type becomes unresolved (e.g., not registered in the current scheduler instance due to a rolling update where new versions don't have the task yet), the compensation batch query unpicks those tasks so they can be processed by other scheduler instances that have the task type available (this behavior is already built-in for FETCH and generic LOCK_AND_FETCH modes out of the box).

Implementation Details

Compensation query in single statement LOCK_AND_FETCH mode:

• Added a transaction. The first query is existed SELECT FOR UPDATE SKIP LOCKED that picks a task. The second query unpicks unresolved tasks if any exist. If there are no unresolved executions, the second query is skipped and only the transaction commit is performed.
• Allows other scheduler instances to pick up unresolved tasks

Unpick operation (unpickPickedBatch repository method):

• Uses a batch update to mark tasks as unpicked (picked = false with version increment).
  If any of the unpicked tasks is not found or has a mismatched version, the method throws an exception.

Tests Added

Several additional tests are added to TaskResolverTest for better coverage.

Fixes

#804

Reminders

• Added/ran automated tests
• Ran mvn spotless:apply

---

cc @kagkarlsson

[strelchm]

There is some tradeoff to add a transaction instead of one query. I think atomicity is better here — the second query will be executed only in rare unresolved task cases, and the transaction impact will be just the second (for batch) roundtrip.

[OptimumCode]

@strelchm Thanks for making the PR! We are currently experiencing a problem with false-positive dead executions because the lock-and-fetch strategy does not unpick unresolved tasks (when they were grabbed by an old worker that does not yet have the task definition). And this PR is just what we need!

[OptimumCode]

nitpick: We could use Boolean.TRUE to avoid unnecessary boxing here (and Boolean.FALSE below)

[strelchm]

Good point, thanks! Fixed.