feat(retry): add JitterFactor to RetryPolicy

[javier-aliaga]

Context

When orchestrations retry failed activities or sub-orchestrations, the retry delay is calculated using exponential backoff (InitialRetryInterval * BackoffCoefficient^attempt). In systems running many concurrent orchestration instances, all retries sharing the same policy configuration will compute identical delays, causing them to fire at the exact same time.

Problem

Without jitter, concurrent retries create thundering herd scenarios — all failing instances retry simultaneously, overwhelming downstream services and increasing the likelihood of repeated failures. This is a well-known distributed systems anti-pattern. Additionally, the existing computeNextDelay function had a bug where the MaxRetryInterval comparison used < instead of >, meaning the delay was never actually capped before being returned.

Solution

Add a JitterFactor field to RetryPolicy (range [0.0, 1.0]) that introduces controlled randomness to retry delays:

• Deterministic jitter: Seeded by firstAttempt + attempt so replays produce identical delays, preserving orchestrator replay safety.
• Configurable reduction: A factor of 0.5 allows up to 50% reduction of the computed delay; 0.0 disables jitter entirely (backward compatible).
• Validation clamping: Validate() clamps out-of-range values to [0.0, 1.0] instead of returning an error.
• Bug fix: Corrected the MaxRetryInterval comparison (< → >) so the delay is properly capped before jitter is applied.
• Nil-safety: WithActivityRetryPolicy and WithChildWorkflowRetryPolicy now handle nil policy gracefully.