Preserve pending activity next retry delay

[spkane31]

What changed?

Fixed standalone activity option updates so a pending retry is not delayed when the worker-provided NextRetryDelay happens to equal the old retry-policy interval.

When recalculating CurrentRetryInterval after UpdateActivityExecutionOptions, the activity now only applies the newly computed policy interval if it shortens the already scheduled retry delay. This preserves the existing retry schedule when a retry-policy update would otherwise move the next attempt later.

Added a regression test for the case where:

• attempt 1 fails with NextRetryDelay=2m
• the current retry policy also had InitialInterval=2m
• the retry policy is updated to InitialInterval=10m
• the pending retry must remain scheduled at 2m, not move to 10m

Why?

#10920 preserved worker-provided NextRetryDelay when it differed from the policy-derived interval, but missed the edge case where the worker delay and old policy interval were equal. In that case, the update path treated the pending retry as policy-derived and recalculated it from the new policy, incorrectly extending the already scheduled retry from 2m to 10m. A retry-policy update should not delay an existing worker-controlled retry.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

Potential risks

Minimal, this is still part of our testing push and not released to production.

[spkane31]

Discussed w/ @fretz12 offline. Decision we came to is we need to have a robust way to distinguish between worker originated retry interval overrides and retry policy computer and only set when the retry policy is recomputer.

if attempt.CurrentRetryIntervalSource == POLICY {
  attempt.CurrentRetryInterval = durationpb.New(interval)
}

This allows updates to override next retry delay and extend or shorten the delay.