bug(graph): computed-condition If stalls on a Collect-of-Collect branch deeper than its condition #9922

Summary

A session stalls when an If with a computed per-item condition selects a branch that is a Collect of a Collect keeping axes deeper than the condition's. next() returns None, is_complete() stays False, and no error is raised, so the queue item hangs.

Reproduction

Nodes (FixedCollectionTestInvocation, AnyTypeTestInvocation and MarkedAnyTypeTestInvocation are from tests/test_nodes.py):

• src: CollectionConcatInvocation(first=[[[["a"], ["b"]], [["c"]]], [], [[["d", "e"]]]])
• Four nested IterateInvocations, each fed from the previous item through a CollectionConcatInvocation(first=<item>): O → M → N → I
• I.item → b1: MarkedAnyTypeTestInvocation(marker="b:") → c0: CollectInvocation (keeps O, M, N open)
• c0.collection → c1: CollectInvocation.item (keeps O, M open)
• O.item → cond: FixedCollectionTestInvocation.value, then cond.condition → if.condition (truthy, falsy, truthy per O item)
• c1.collection → if.true_input
• fb: AnyTypeTestInvocation(value="fb") → if.false_input
• if.value → collect: CollectInvocation.item

Run it with GraphExecutionState on main (seen at ac237a1) or on #9789 (174c137), on both schedulers.

Observed: the session stalls and collect is never produced.

Expected: the true branch keeps axes (O, M) deeper than the condition's (O), and the false branch is a root value. That is the asymmetric case that #9843 rejects for a single branch Collect: the same graph with c0.collection feeding if.true_input directly raises UnsupportedIfIterationAxesError before any node runs. The Collect-of-Collect version should be rejected the same way.

Variant: with the false branch taking a marked copy of c1.collection (c1.collection → MarkedAnyTypeTestInvocation(marker="f:") → if.false_input), both branches share the same deeper axes, which is a supported shape. It also stalls. Expected: it completes.

Notes

The branch-Collect check reads a branch Collect's kept axes through one level only. A Collect fed by another Collect looks as if it keeps no axes, so the shape passes validation. Making that check see through Collect chains is not enough by itself: the stricter check then accepts a sibling shape where one branch is a single Collect and the other a Collect of a Collect with the same kept axes, and that shape also stalls at runtime. A fix needs runtime support for Collect-of-Collect branches under a per-item condition, or an explicit rejection of them.

Found during review of #9789.