Jobs silently get one extra retry beyond max_retries

max_retries is a contract: a job owner sets it expecting exactly that many attempts before chronos gives up and dead-letters the run for them to investigate. Silently granting one extra attempt beyond what was configured breaks that contract for every single job in the system, not just an edge case. For a job whose target_url triggers a paid API call, sends a customer notification, or charges a card, "one extra attempt beyond what I configured" is an unauthorized action the job owner explicitly tried to prevent by setting max_retries in the first place.

pkg/queue/queue.go's MarkRetry decides whether to dead-letter with if attemptCount > maxRetries. attemptCount here is the attempt that just failed. With max_retries = 2, the call sequence is: attempt 1 fails (attemptCount=1, requeue), attempt 2 fails (attemptCount=2, 2 > 2 is false, requeue again), attempt 3 fails (attemptCount=3, finally dead-letter). That's 3 attempts for a job configured for 2.

1. Create a job with max_retries: 2 pointing at /demo/webhook/always-fail.
2. Trigger it and let it fail out completely (or call MarkRetry directly with attemptCount=2, maxRetries=2).
3. Check the run's final attempt_count and status -- it will show 3 attempts before dead, not 2.

This is a boundary condition on when "at the limit" becomes "over the limit" -- > vs >= -- the single most common flavor of off-by-one bug, and one that's easy to miss in review because both read as plausible at a glance.

Think through the exact sequence of attemptCount values MarkRetry sees across a job's failed attempts, and at which value the Nth (final) attempt should stop being retried and start being dead-lettered.