[flake8-simplify] Preserve operand order in SIM109 fix

[alzeph]

Summary

Fixes #18945.

compare-with-tuple (SIM109) merges repeated equality checks against the same target into a single in comparison, e.g. a == b or a == c becomes a in (b, c). When the boolean expression also contains unrelated operands, the fix always placed the merged in comparison first and appended the unmatched operands after it, regardless of where they originally appeared. That reorders the expression and can change its value under short-circuit evaluation:

x = None
y = "y"
z = "z"
w = "w"
print(x or y == z or y == w)  # False

was fixed to:

print(y in (z, w) or x)  # None

Fix

The merged in comparison is now anchored to the position of its earliest matched comparator, and sorted together with the unmatched operands by position instead of always being placed first. This preserves the original order for operands that appear before or after the group of merged comparisons.

There's one case this doesn't fully solve: if an unmatched operand sits between two merged comparisons (e.g. a == b or None or a == c), there's no reordering that keeps both the merged comparison contiguous and every operand in its original position, so it's still moved after the merged comparison. I've documented this as a known limitation in the rule's ## Fix safety section, along with a regression test that pins down the current (documented) behavior.

This follows the approach @ntBre sketched in review on the earlier attempt at this fix (#19753, closed for inactivity).

Test plan

• Extended SIM109.py with a regression case for the exact scenario from the issue (unmatched operand before the merged comparisons) and kept/annotated the existing case that demonstrates the documented limitation (unmatched operand between merged comparisons).
• Reviewed the updated snapshot diff.
• Ran the flake8_simplify test suite, clippy, and cargo dev generate-all (doc comment change).

[ntBre]

Thank you! And sorry for the delay. I resolved the merge conflicts and then applied a very minor simplification with itertools, but this looked good to me!