Fix batched finish worker reenqueue delay

What does this MR do and why?

Fix batched finish worker reenqueue delay

Calling perform_in with a timestamp in the past has the same effect as enqueueing with no delay.

Triggering code:

key = SecureRandom.hex
# 00a25616552d6bfa5533d8ce194739f4
(pp Time.current) && Worker.perform_in(30.seconds.ago, key)

sidekiq.log:

{
  "message":"00a25616552d6bfa5533d8ce194739f4 2024-05-23 12:24:55 UTC"
}

This MR fixes an invalid usage of perform_in so that the delay is properly respected (not account for Sidekiq's own polling interval.)

Changelog: fixed

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.