Fix Redis queue retry_after being shorter than Horizon's timeout

config/queue.php's redis connection defaulted retry_after to 90s,
while config/horizon.php's supervisor-1 defaults to a 300s timeout
in both environments. Per Horizon's documented timeout-chain
requirement (job timeout < supervisor timeout < retry_after), this
was backwards: any job legitimately running between 90s and 300s
would get treated as dead by the queue driver and picked up by a
second worker before Horizon's own supervisor had a chance to time
it out, causing the same job to run twice concurrently.

Bumps the default to 330s (a 30s margin over the supervisor timeout)
and documents the relationship inline so it doesn't regress if
either value is tuned later.

config/queue.php

@@ -68,7 +68,12 @@ return [
             'driver' => 'redis',
             'connection' => env('REDIS_QUEUE_CONNECTION', 'default'),
             'queue' => env('REDIS_QUEUE', 'default'),
-            'retry_after' => (int) env('REDIS_QUEUE_RETRY_AFTER', 90),
+            // Must stay greater than Horizon's supervisor `timeout`
+            // (config/horizon.php, default 300s). Otherwise a job that's
+            // still legitimately running gets treated as dead and picked up
+            // by a second worker before Horizon has a chance to time it out
+            // itself, causing the same job to run twice concurrently.
+            'retry_after' => (int) env('REDIS_QUEUE_RETRY_AFTER', 330),
             'block_for' => null,
             'after_commit' => true,
         ],