plugins-guide: concrete patterns for duplicate-side-effect testing (#4481)

The previous text ("Check for duplicate side effects or other types of
failures") did not give readers enough to act on. Retrying activities
can cause a simple execution counter to flake even when the plugin is
correct, so replace the vague line with two patterns that are invariant
under activity-task retries: counting ActivityTaskScheduled events in
history, or accumulating activity IDs in a set.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Brian MacDonald <brian.macdonald@temporal.io>

Author: 3 people

docs/develop/plugins-guide.mdx

@@ -976,6 +976,9 @@ worker = Temporalio::Worker.new(
   </SdkTabs.Ruby>
 </SdkTabs>
 
-Check for duplicate side effects or other types of failures.
+Inside this replay regime, you should test for duplicate side effects or other types of failures. When testing for duplicate side effects, it may not be sufficient to simply have a counter that increments once per effect, as activities may be retried. Instead, consider these patterns:
+
+- count `ActivityTaskScheduled` events of the expected activity type in workflow history (one per intended call, independent of retries), 
+- or accumulate activity IDs in a concurrency-safe set and assert on its size (different scheduled activities get different IDs; retries of the same scheduled activity share one).
 
 It's harder to test against side effects to global variables, so this practice is best avoided entirely.