#55420 Fix: Unique lock not being released after transaction rollback in ShouldBeUnique jobs with afterCommit()

This pull request addresses an issue where ShouldBeUnique jobs scheduled with afterCommit() would fail to execute after a transaction rollback.

The problem occurred because when a ShouldBeUnique job is dispatched, a unique lock is created. Under normal circumstances, this lock is released after the job has been executed successfully. However, if the transaction within which the job was dispatched rolled back, the unique lock would remain in place. This would prevent any subsequent dispatch of the same ShouldBeUnique job from being processed, as the unique lock would still exist.

This pull request introduces a fix to ensure that when a transaction rollback occurs, any associated unique locks created by ShouldBeUnique jobs dispatched with afterCommit() are properly released. This ensures that the jobs can be dispatched and executed correctly even after a transaction rollback.

e.g.

• some job

class SampleJob implements ShouldQueue, ShouldBeUnique
{
    ...
}

• job dispatch

\DB::transaction(function() {
    SampleJob::dispatch()->afterCommit();

    // Exception occurred
    // At this time, the transaction is rolled back, but the unique lock for the job remains.
    // As a result, the job will not be executed again until the unique lock times out.
    // This PR fixes that issue.
});