Summary

Refs #297 — Eliminates the unconditional ContinueWorkflowTagFanout self-message that was causing a performance regression in v0.18.3.

Problem

In v0.18.3, all tag-based fanout operations (SendSignalByTag, CancelWorkflowByTag, etc.) unconditionally produce a ContinueWorkflowTagFanout message back to the topic before doing any work. This adds an extra Pulsar round-trip for every operation, even when the tag has a single workflow ID.

Production metrics showed: 82ms → 7,084ms avg processing time (86x regression), 10,851 in-flight messages backlog.

Fix

The first page of workflow IDs is now fetched and fanned out inline during the initial message processing. ContinueWorkflowTagFanout is only produced when there are additional pages (nextCursor != null).

Before:

SendSignalByTag → produce ContinueWorkflowTagFanout → consume → getWorkflowIdsPage → fanout

After:

SendSignalByTag → getWorkflowIdsPage → fanout (→ produce ContinueWorkflowTagFanout only if more pages)

For tags with fewer IDs than fanoutPageSize (the common case), no ContinueWorkflowTagFanout is produced at all. Pagination for large tags still works via continuations for subsequent pages.

What was tested

All existing tests updated and passing (10/10). Tests verify:

• Small tags: inline fanout, no continuation produced
• Large tags (fanoutPageSize=1): first page inline, continuation for subsequent pages
• Full pagination: all pages fanned out correctly
• Batch processing equivalence: batch and one-by-one produce identical results