Description

Fixes #2316.

When a (nullable) source type defines multiple user-defined equality/inequality operator overloads - the strongly-typed value object pattern, e.g. both ==(Code?, Code?) and ==(Code?, string?) - Mapperly's generated null check source.X != null could not be resolved by the compiler and failed with:

error CS9342: Operator resolution is ambiguous between the following members:
'Code.operator !=(Code?, Code?)' and 'Code.operator !=(Code?, string?)'

because the bare null literal is convertible to more than one operand type.

Fix

The null literal in the generated null checks is now cast to the nullable source type (e.g. (global::Code?)null) when the operand type declares more than one ==/!= overload. This disambiguates the comparison while preserving behaviour, and works for both object mappings and queryable projection expression trees.

Types with a single operator overload (such as string) are left untouched, so there is no change to existing generated code (no snapshot churn).

The cast is threaded through the existing null-check generation:

• MemberNullDelegateAssignmentMapping (object mapping if (source.X != null))
• MemberPathGetter (queryable projection source.X != null ? ... : default)
• NullDelegateMapping (nested null handling)
• IfNoneNull / IfAnyNull

Detection lives in a new ITypeSymbol.HasAmbiguousEqualityOperators() helper.

Tests

• CastTest.NullableSourceWithMultipleUserDefinedEqualityOperatorsShouldCastNullLiteral: object mapping body.
• CastTest.NullableSourceWithMultipleUserDefinedEqualityOperatorsShouldCastNullLiteralInProjection: queryable projection snapshot.

The full unit test suite passes with no other snapshot changes. Confirmed in a standalone compilation that the previous output fails with CS9342 while the new (global::Code?)null output compiles.

Checklist

• I did not use AI tools to generate this PR, or I have manually verified that the code is correct, optimal, and follows the project guidelines and architecture
• I understand that low-quality, AI-generated PRs will be closed immediately without further explanation
• The existing code style is followed
• The commit message follows our guidelines
• Performed a self-review of my code
• Hard-to-understand areas of my code are commented
• The documentation is updated (as applicable)
• Unit tests are added/updated
• Integration tests are added/updated (as applicable, especially if feature/bug depends on roslyn or framework version in use)