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.

[vikas0686]

Thanks for the review and the feedback!

Just checking if there's anything else you'd like me to update or address in this PR before it's ready to merge. Happy to make any additional changes if needed.