feat: Enable use of WorkflowCombineTesting without specifying a concrete Publisher type

[amorde]

Changes

• Add expectPublisher(producingOutput:key:) API that is generic only over the output of the publisher rather
• Update PublisherWorkflow to only be generic over the output rather than the Publisher type

Rationale

The current API shape requires that tests pass in a concrete Publisher type. This can be quite tedious depending on the context, resulting in having to pass in types like Publishers.Map<AnyPublisher<Bool, Never>, AnyWorkflowAction<SomeWorkflow>>>.

This differs from WorkflowReactiveSwift, for example, which has a workflow that is only generic over the output and has an expect API that only requires providing the output type

Checklist

• Unit Tests
• UI Tests
• Snapshot Tests (iOS only)
• I have made corresponding changes to the documentation

[amorde]

Note: This change has the side effect of making this worker only unique against the output of a publisher rather than the concrete publisher type. This can result in two different workers overlapping if they do not specify a key and have the same output type (e.g. Bool).

This is already true for WorkflowReactiveSwift but is a new change for WorkflowCombine

[robmaceachern]

Some ai suggestions related to this:

I dug further on this and added a repro test showing that this change really does alter runtime behavior: switching between different concrete publisher types with the same output/key no longer forces a resubscribe.

That said, I couldn’t find a strong real-world breakage in ios-register, and WorkflowReactiveSwift already has effectively this behavior today. So I think the important question is whether we want WorkflowCombine to intentionally match those semantics.

If yes, I think this is probably fine, but it should be treated as an explicit behavior change rather than incidental test cleanup:

• keep/add the repro test
• document the caveat similarly to WorkflowReactiveSwift

If no, then we should preserve the existing concrete-publisher identity and keep this PR scoped to testing ergonomics.

[amorde]

Yep - this 100% would break something relying on this, but since we haven't used WorkflowCombine nearly as much as we use WorkflowReactiveSwift it should be relatively safe. The framework will throw an assertion if there's overlap

[johnnewman-square]

I also asked Claude to investigate and found that every usage in register erases to AnyPublisher:

So the behavioral concern — two different concrete publisher types collapsing into the same workflow identity — doesn't apply in practice. Everyone is already erasing to AnyPublisher before calling .running(), which means the concrete type parameter is already AnyPublisher<Output, Never> at runtime today.

[robmaceachern]

@codex review

[johnnewman-square]

This looks good 👍

[johnnewman-square]

I also asked Claude to investigate and found that every usage in register erases to AnyPublisher:

So the behavioral concern — two different concrete publisher types collapsing into the same workflow identity — doesn't apply in practice. Everyone is already erasing to AnyPublisher before calling .running(), which means the concrete type parameter is already AnyPublisher<Output, Never> at runtime today.