fix: add missing @TemporalDsl receiver annotation to setRetryOptions extensions

[vikas0686]

Problem

Three setRetryOptions extension functions were missing @TemporalDsl on the receiver type:

// Before (missing annotation on receiver)
inline fun ActivityOptions.Builder.setRetryOptions(
  retryOptions: @TemporalDsl RetryOptions.Builder.() -> Unit
)

LocalActivityOptionsExt already had the correct pattern:

// Correct (receiver is annotated)
inline fun @TemporalDsl LocalActivityOptions.Builder.setRetryOptions(
  retryOptions: @TemporalDsl RetryOptions.Builder.() -> Unit
)

Without @TemporalDsl on the receiver, Kotlin's @DslMarker mechanism cannot enforce scope isolation. Inside a setRetryOptions { } block, the outer ActivityOptions.Builder (or ChildWorkflowOptions.Builder / WorkflowOptions.Builder) remains an implicit receiver, so callers can accidentally invoke outer-scope builder methods inside the nested lambda — exactly the problem @TemporalDsl is designed to prevent.

Fix

Added @TemporalDsl to the receiver of setRetryOptions in:

• activity/ActivityOptionsExt.kt
• workflow/ChildWorkflowOptionsExt.kt
• client/WorkflowOptionsExt.kt

Tests

Added a standalone test in each of the three corresponding test classes that calls setRetryOptions directly on a builder instance (rather than only through the outer DSL), covering the extension function in isolation.

Notes

This is a compile-time correctness fix — r Existing code that uses ```
setRetryOptions {
}

Thanks for review and feedback

[Quinn-With-Two-Ns]

Hi thanks for the contribution, I agree this is just an oversight when we added the DSL annotations we forgot to annotate the setRetryOptions. Technically this is a breaking change because before, if I am understanding the issue, we would have allowed this code:

ActivityOptions {
  setRetryOptions {
    setInitialInterval(...)   // RetryOptions.Builder — fine
    setTaskQueue("q")         // ActivityOptions.Builder — was silently allowed, will now fail to compile
  }
}

and now after we will not. Personally I think that is a reasonable break because it will be a compile time break, should be very trivial to fix (just move the function outside of setRetryOptions) and I doubt any user would intentionally do this. @maciejdudko thoughts?

[maciejdudko]

@Quinn-With-Two-Ns Agreed, I think this change in behavior is fine.