Fix unique-job lock leak in inline testing mode

[lovitt]

Problem

In inline mode (Cloudtasker::Testing.inline!), a unique job runs only the first time it's enqueued — later enqueues of the same job are silently rejected.

lock_for_scheduling! (added in 0.15.0) takes a provisional lock, yields to enqueue the job, then takes the final lock. That final lock is meant to be released later, when the job runs — the execute middleware unlocks it.

But in inline mode the job runs during the yield, so it unlocks before the final lock is even taken. The final lock is then set after the job has already finished, leaving it with no future run to release it. It lingers for the full lock_ttl and rejects later enqueues of the same job (on_conflict: :reject). 0.14.0 did a plain lock!; yield, so this is a regression.

Cloudtasker::Testing.inline! do
  TestUniqueJobWorker.perform_async(1, 2)
  TestUniqueJobWorker.perform_async(1, 2)
end
# before: [[1, 2]]            (second rejected)
# after:  [[1, 2], [1, 2]]

Fix

Skip the final-lock step in inline mode, where the job has already run and released its lock. The async/production path is unchanged: inline_mode? is guarded by defined?(Cloudtasker::Testing), which is false in production (same idiom as CloudTask.backend).

Tests

Integration spec (both inline enqueues run) and unit spec (lock not promoted to the final TTL).

[lovitt]

Superseded by the upstream PR keypup-io#173, which carries the same fix based on keypup-io/master. Closing in favor of that one.