fix(match): enum literal narrowing is order-sensitive in match statements

[Bahtya]

Fix for #21187

Problem

When matching a union containing Literal[SomeEnum.VALUE] and other types (e.g., DummyClass), the order of match cases affected type narrowing results:

• case DummyClass(): ... case MyEnum.RELEVANT: → ✅ works correctly
• case MyEnum.RELEVANT: ... case DummyClass(): → ❌ false positive on assert_never

This is a regression from mypy 1.19 to 1.20.

Root Cause

visit_value_pattern in checkpattern.py uses narrow_type_by_identity_equality with "==" semantics. This function has a conservative enum ambiguity check that skips narrowing for StrEnum/IntEnum types because they can compare equal to str/int values. While this is correct for general equality comparisons (if x == MyEnum.RELEVANT:), it is overly conservative in match statements where the other union members (like DummyClass) are unrelated types.

Solution

For enum literal values without custom __eq__, bypass narrow_type_by_identity_equality and use conditional_types_with_intersection directly (same approach used by visit_singleton_pattern). This correctly narrows based on the literal value regardless of the enum's base type ambiguity with str/int.

Enums with custom __eq__ are excluded to preserve the existing narrowing behavior (where the type stays as the full enum type, not narrowed to a specific literal).

Testing

• Reproduced the bug from [1.20 regression] Type narrowing is order sensitive in match-case statement with narrowed enum type #21187 — confirmed fix resolves it
• Verified with both StrEnum and IntEnum
• All 253 match-related tests pass
• All 375 literal/enum tests pass
• All 197 python310 tests pass
• No regressions in testMatchLiteralPatternEnumCustomEquals (custom __eq__ still respected)

Fixes #21187

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅