[CaffeinatedCoder]

Closes #452

Problem

#385 keeps a range comparer's Compare out of SQL, but it decided by the parameter type Compare declares. A comparer declared over IRange<T>, the non-generic System.Collections.IComparer (including Comparer<DateRange>.Create(…) held as one) and any comparer of value sets declare a type RangeTypeRegistry doesn't hold, so EF Core still read the call as the natural order. With p = [2026-03-01,2026-03-10], Where(r => cmp.Compare(r.Period, p) == 0) became WHERE r."Period" = @p and returned one row where memory returns three. The changelog row, docs/efcore.md#what-runs-where and the migration guide all promise that every IComparer of ranges or sets fails translation.

Change

• ValueRangesQueryExpressionInterceptor.RangeComparerRewriter: rewrites when either operand is a range, range set or value set. It checks the operand itself and each conversion on its way to the declared type, and reaches a sealed variant through its union. The comparer must still implement IComparer<TDeclared> or, for Compare(object, object), the non-generic IComparer.
• RangeComparerCall: a RunInMemory(IComparer, object?, object?) overload with the same name, so EF's error message still shows RangeComparerCall.RunInMemory.
• docs/efcore.md (What runs where) and docs/migration.md (Move RangeLowerBoundComparer out of queries) name the three kinds. Claim E31 says the operands decide.
• The CHANGELOG.md row already says "any other IComparer of ranges or sets", so it is unchanged here. The 10.x cherry-pick links this issue from 10.x: RangeLowerBoundComparer.Compare in a query runs in the range order (port of #385) #396's row, as pr-hygiene.sh requires for a silent PR into a minor.

Tests

• ClientSideOnlyTranslationTests: Where and OrderBy rows for an IComparer<IRange<DateOnly>>, a non-generic IComparer and an IComparer<StringSet>.
• LowerBoundComparerQueryTests (live PostgreSQL 16): the same comparers, plus Comparer<DateRange>.Create as IComparer and a comparer class of our own. Each fails translation in Where and OrderBy with RangeComparerCall.RunInMemory in the message. In a final Select each gives memory's answer; for value sets the test adds a Tags column and compares by count against {z}.
• Reverted: with the old declared-type check put back, the six new translation rows fail, the live filter query returns rows instead of throwing, and the projection reads the NULL row's Compare from SQL. That proves the tests catch the bug.
• A trap the tests avoid: a comparer held in a static readonly field reaches EF as a constant, and EF never translates Compare on a constant, so those rows fail with or without the fix. The comparers in both tests are captured locals, so they become query parameters, which is the case the review reproduced.
• EF unit tests (330), the conventions tests (417), and TranslationSupportProbeTests, CapturedCollectionProbeTests, ClientSideOnlyProjectionTests and LowerBoundComparerQueryTests live all pass. The seed lower-bound-comparer-runs-as-sql.patch still applies.

🤖 Generated with Claude Code