The previous commit wired targetTaskId through the engine caller but the
store's acquireMergeQueueLease SQL still grabbed the queue head unconditionally,
leaving the no-lease loop intact. This lands the store-side change: when
targetTaskId is provided it attempts a direct-match UPDATE first; only falls
back to queue-head ordering if that row isn't available (backward-compatible).
Adds regression test covering the polluted-queue-head scenario (FN-5363).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>