Reclaimed runs never count toward max_retries

A job whose target never responds at all (hangs forever, or the network path is broken such that the worker's HTTP call never returns before the lease expires) is only ever recovered by the reaper's blind reclaim -- the worker itself never gets to call MarkRetry or MarkDead. If reclaiming doesn't increment attempt_count, that job retries forever: attempt_count stays frozen, it can never reach max_retries, and it never dead-letters. This is a silent resource leak with no ceiling -- a single misconfigured or unreachable target_url generates an unbounded stream of retries indefinitely, consuming worker capacity that should be going to healthy jobs, with nothing in the dead-letter queue to alert anyone that something is stuck.

pkg/queue/queue.go's ReclaimExpiredLeases requeues expired leases but never touches attempt_count in its UPDATE. Every reclaim leaves it exactly where it was.

1. Insert a job_runs row with attempt_count = 3 and an already-expired leased_until.
2. Call ReclaimExpiredLeases.
3. Check the row's attempt_count -- it's still 3, not 4.

This is a missing side effect in an UPDATE statement -- easy to omit because the statement still "does something correct" (it does requeue the row), just not everything it needs to.

Compare this UPDATE's SET clause against MarkRetry's, right above it in the same file -- MarkRetry sets attempt_count explicitly to a caller-provided value; this one needs to increment the column's current value instead (since there's no separate caller-computed value here, the row itself needs to move it forward by one).