Add chaining to Collect node

[JPPhoto]

Summary

Feature + fix: enhanced the built-in collect node to support chaining via collect.collection while preserving existing multi-collect.item behavior.

Why:

• Enable native Collect -> Collect workflows (similar to @skunkworxdark's collection_tools) without breaking existing graphs.
• Keep collector type safety intact across chained and mixed connection order scenarios.
• Align frontend connection validation with backend graph validation.

How:

• Backend (invokeai/app/services/shared/graph.py):
  • collect updated to version="1.1.0".
  • Exposed collection as a real connection input.
  • Kept multi-input behavior for item, single-input behavior for collection.
  • Updated collect input preparation to merge upstream collections + local items.
  • Strengthened collector type resolution for:
    • chained collectors,
    • Any-only collector inputs,
    • union collection annotations containing list branches (T | list[T] | None).
• Frontend:
  • Unhid collect.collection in schema parsing.
  • Updated collect type inference utility to resolve type through collection chains.
  • Updated node util test fixture for collect input typing.

Related Issues / Discussions

https://discord.com/channels/1020123559063990373/1130288930319761428/1477387080966471802

QA Instructions

Backend:

1. Run:
   • pytest -q tests/test_node_graph.py -k "collector or iterate_accepts_collection or iterate_validates_collection_inputs_against_iterator_outputs"
2. Confirm collector-chain and type mismatch tests pass, including:
   • late-added upstream mismatch rejection,
   • Any-only collector -> iterate acceptance,
   • union collection input mismatch rejection.

Frontend:

1. Run:
   • cd invokeai/frontend/web && pnpm run lint:tsc
   • cd invokeai/frontend/web && node_modules/.bin/vitest run src/features/nodes/store/util/getCollectItemType.test.ts src/features/nodes/store/util/validateConnection.test.ts
2. Confirm no TS errors and tests pass.

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)

[skunkworxdark]

I have looked through the code, and the bits I understand look good.

TBF, a lot of it is over my head. I really don't do much front-end code and haven't delved into the graph execution stuff anyway as much as you have. There is much more code change than I'd expected, which is related to graph execution and traversal, so I can't comment on it in any real, meaningful way that would be helpful.

One thing that comes to mind is, have you considered circular references now that they can be linked together, or is that already done via the front end?

IMHO, this carries much more risk than extending only the primitive collection nodes. However, it does provide a much more centralised solution. The collect node is a core component used in many places; it needs extensive testing to cover the many different scenarios it can be used in.

Sorry, I wish I were more helpful.

[skunkworxdark]

I assume with this change, none of my collection_tools node packs will be needed at the moment.

[JPPhoto]

One thing that comes to mind is, have you considered circular references now that they can be linked together, or is that already done via the front end?

The front end prevents this condition for all nodes.

IMHO, this carries much more risk than extending only the primitive collection nodes. However, it does provide a much more centralised solution. The collect node is a core component used in many places; it needs extensive testing to cover the many different scenarios it can be used in.

Agreed.