💥 Carry over search attributes on continue-as-new if none are explicitly set

[Quinn-With-Two-Ns]

Carry over search attributes on continue-as-new if none are explicitly set, this is the documented behaviour but previously the Java SDK was not actually carrying over search attributes.

closes #2178

---

Note

Carry over existing SearchAttributes during continue-as-new when none are specified, and add tests verifying typed attributes and retry options propagation.

• Workflow runtime (continue-as-new):
  • Carry over existing SearchAttributes if none are provided:
    • When ContinueAsNewOptions has neither searchAttributes nor typedSearchAttributes.
    • When options is null (also continues copying RetryOptions).
• Tests:
  • Expand ContinueAsNewTest to use typed search attributes and assert their propagation across continue-as-new runs alongside RetryOptions.
  • Enable external service in test rule and adjust assertions.
• Docs:
  • Minor grammar tweak in ContinueAsNewOptions Javadoc.

^{Written by Cursor Bugbot for commit 296c6b2. This will update automatically on new commits. Configure here.}

[cretz]

Technically this is a change to behavior incompatibly if people have built expectation on the carryover not occurring. Should we add a 💥 in the title and note it in release notes? I assume if they want to go back to today's behavior they can provide an explicit empty attr collection?

(not reviewing the PR itself, just confirming the relaying of compatibility change)

[Quinn-With-Two-Ns]

So according to the Javadoc the behaviour has always been to copy if none are specify, the SDK just hasn't been. This is a change in behavior so I have no issue calling it out with 💥 .

And yes if a user wants the previous behaviour they can set an empt collection.