Added If node and ability to link an Any output to a node input if cardinality matches

[JPPhoto]

Summary

This PR includes a feature + bugfix for the new If invocation and its editor interoperability:

• Added a new If invocation node (if) with:
  • input condition: bool
  • input true_input: Optional[Any]
  • input false_input: Optional[Any>
  • output value: Optional[Any] (with default=None to avoid persisted-session validation failures when omitted).
• Fixed frontend node-connection validation so AnyField can be used as a source where cardinality is compatible (instead of being blocked), which allows If.value to connect to typed inputs in the UI.
• Added/updated tests for:
  • If true/false behavior and graph connectivity
  • deserialization of if_output when value is missing
  • AnyField source compatibility and cardinality guardrails in UI connection typing.

Why:

• Enable practical conditional branching in workflows.
• Ensure the UI allows intended If output wiring.
• Prevent session reload crashes caused by missing if_output.value in persisted JSON.

How:

• Implemented the invocation in backend Python.
• Updated frontend type compatibility logic.
• Added focused regression tests on both backend and frontend paths.

Related Issues / Discussions

QA Instructions

1. Backend schema/output checks

   • Verify IfInvocationOutput.value is optional with default None.
   • Verify deserialization test exists and passes in a full dev environment.

2. UI connection behavior checks

   • Create a graph with If node and connect If.value to a typed input (e.g. string input).
   • Confirm connection is accepted for compatible cardinalities, and rejected for incompatible ones (e.g. SINGLE -> COLLECTION).

3. Automated tests

Merge Plan

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[dunkeroni]

Singleton cases all work well, and I like that the type restrictions on the inputs to prevent footguns. I have some issues with the handling around collections though:

1. Collection and Singleton inputs are (intentionally) not allowed together. We do have inputs that accept unions of singleton and collection types (e.g. loras), and having to wrap the singleton input in a collect node is a bit awkward since most of the collection inputs we have on other nodes are this combined type. Speaking of which...
2. The Output can only connect to single or union[single+collection] types. If I am picking between two collections on the inputs, I cannot connect the output to an Iterate, collection primitive, or any other node that requires the input to be a collection. Should we split this off to an If (collection) version that outputs exclusively collection types?

[JPPhoto]

Singleton cases all work well, and I like that the type restrictions on the inputs to prevent footguns. I have some issues with the handling around collections though:

1. Collection and Singleton inputs are (intentionally) not allowed together. We do have inputs that accept unions of singleton and collection types (e.g. loras), and having to wrap the singleton input in a collect node is a bit awkward since most of the collection inputs we have on other nodes are this combined type. Speaking of which...
2. The Output can only connect to single or union[single+collection] types. If I am picking between two collections on the inputs, I cannot connect the output to an Iterate, collection primitive, or any other node that requires the input to be a collection. Should we split this off to an If (collection) version that outputs exclusively collection types?

I'll see about changing this to accept a Singleton of the same type as the Collection. I'd rather do that than have a second If (collection) node.