Equivalency: fail when applying member-level selection to value-semantics (fixes #2571)

[WillRayAtPropertyMe]

Summary

This change enforces a clear failure when callers attempt to apply member/path-level selection rules (e.g., Excluding(...), Including(...) by path) to types that are compared using value semantics (i.e., Equals override or explicit ComparingByValue/ForceEquals). Previously such rules could be silently ignored or produce inconsistent behavior across overloads.

What I changed

• Equivalency logic

  • Src/FluentAssertions/Equivalency/EquivalencyValidator.cs
    • Added checks so that when a path-based selection rule (currently ExcludeMemberByPathSelectionRule) targets a node whose type is compared by value semantics, the assertion fails with an actionable message explaining how to resolve the issue (for example, ComparingByMembers<T>()). The check is conservative: it ignores primitive/value types and string, and it only fails for non-primitive reference types which either override Equals or are explicitly forced to use Equals.

• Tests

  • Tests/FluentAssertions.Equivalency.Specs/SelectionRulesSpecs.Excluding.cs
    • Added a spec that asserts Excluding(...) on a type that overrides Equals results in a helpful failure instead of being silently ignored.
  • Tests/FluentAssertions.Equivalency.Specs/TestTypes.cs
    • Added a small ValueSemanticWithProperty helper type used in the spec.

Rationale

• The behavior described in GitHub issue Excluding and Including options should fail when applied on types with value semantics fluentassertions/fluentassertions#2571 is confusing: users expect that when they specify member-level exclusions or inclusions, those rules are honored or reported; silently ignoring them is a poor developer experience. The maintainers' preferred approach is to fail with a clear message (rather than implicitly switching equality strategy).

Notes & limitations

• This initial implementation enforces the rule for path-based selection rules (exclude-by-path). It does not yet enforce for predicate-based selection rules (Excluding(ctx => ...)) because those can apply at arbitrary depths and require more nuanced runtime analysis to decide whether they definitely target a specific type/member. I can extend enforcement to include predicate-based rules in a follow-up change.

• The check ignores primitive types and string because excluding members that are primitive or strings is harmless and expected.

• I ran the full test suite locally. All test cases executed, and 18610 tests passed; a single build error was emitted by one legacy test target due to an outdated VSTest MSBuild target on .NET 10 (this is unrelated to the change).

How to review

• Focus on EquivalencyValidator.cs for enforcement logic and the small test added to the existing specs.
• If acceptable, I can extend the enforcement to include IncludeMemberByPathSelectionRule and consider predicate-based rules.