fix: make ExponentialBackoff concurrency-safe

[fazilnbr]

Data race in ExponentialBackoff supplier causes "index out of range" panic under concurrent polling

• Guard shared random source with a mutex to prevent concurrent access
• Fix race condition in defaultBackoffSupplier during retry delay generation
• Prevent "index out of range" panics when multiple job pollers call SupplyRetryDelay simultaneously

Description

ExponentialBackoff uses a shared package-level defaultBackoffSupplier, which contains a single *rand.Rand instance. Since math/rand.Rand is not concurrency-safe, concurrent calls to SupplyRetryDelay() can corrupt the RNG state and cause panics such as:

panic: runtime error: index out of range [-2]

This change makes the shared supplier concurrency-safe by protecting access to the random source with a mutex.

Changes

• Add a shared mutex to ExponentialBackoff
• Initialize the mutex in the builder
• Lock around e.random.Float64() in computeJitter

Testing

• Added a concurrency regression test that invokes SupplyRetryDelay() from multiple goroutines against a shared supplier
• Verified with go test -race ./pkg/worker/...
• Verified build passes successfully

Fixes

Fixes #<ISSUE_NUMBER>

Type of Change

• Bug fix (non-breaking change)

Checklist

• Tests added/updated
• Existing tests pass
• No breaking API changes

[CLAassistant]

All committers have signed the CLA.