onnxruntime

f3c4f31e - Fix duplicate node name when QDQ fusion absorbs a redundant Clip/Relu (#33115)

Fix duplicate node name when QDQ fusion absorbs a redundant Clip/Relu (#33115) ## Problem When a Relu/Clip between a QDQ fusion target and its Q node is made redundant by the Q range, the selector records it (`redundant_clip_node`) but `BaseSelector::Select` never adds it to the removal set. The target then survives `CanSafelyRemoveNode` and collides with the same-named `QLinear*` replacement: `two nodes with same node name`. `ReluQuantFusion`/`ClipQuantFusion` normally remove the activation first, so this only occurs when they can't: a Q with no zero-point input, or Clip bounds produced by DQ nodes. ## Fix In `BaseSelector::Select`, append the redundant Clip/Relu index after the outputs of the selected indices, so it is removed with the group. Input/target/output positions, `num_inputs`/`num_outputs` and the ORT-format layout are unchanged. Graphs without a redundant Clip/Relu are unaffected. ## Testing New `QDQTransformerTests.ConvRedundantActivationNotFusedIntoQ` (both cases above): fails without the fix with the error above, passes with it. 196/196 QDQ, NodeUnit, runtime-optimization and selector-action tests pass (Linux x86, Release). Standalone repro models (Conv and Gemm, named and unnamed target) fail to load without the fix and load with it, with outputs identical to the unoptimized reference. Co-authored-by: Yuduo Wu <yuduow@qti.qualcomm.com>