Fix ordering detection and placement

[SimonCropp]

Four correctness fixes and two performance changes, one commit each.

Ordering nested in a lambda suppressed the default ordering

QueryAnalyzer was an ExpressionVisitor that descended into every node, including the lambdas passed to operators. Any OrderBy inside a subquery lambda set HasOrdering, so the query was treated as explicitly ordered and got no default ordering at all:

context.Employees.Where(_ => _.Tasks.OrderBy(task => task.Title).Count() >= 0)

-- before: no ORDER BY at all
select e.Id, ... from Employees as e where (select COUNT(*) ...) >= 0

Include and Select lambdas already had hand rolled guards against this. Every other operator did not, so Where, Any, SelectMany and GroupBy all triggered it, as did an ordering nested inside a filtered Include.

Replaced the visitor with a walk of the chain itself, which is the only place top level ordering and Include can appear.

Ordering was applied after the operators that choose rows

Ordering was only pushed beneath Select and Include, and appended to the end of the chain otherwise. So Take produced:

select * from (select top(3) * from Employees) order by HireDate desc

Three arbitrary rows, sorted after the fact. Paging could skip and repeat rows across pages while looking correctly sorted, and EF Core still raised RowLimitingOperationWithoutOrderByWarning.

First, FirstOrDefault, Last, LastOrDefault and ElementAt were missed entirely: their result type is the entity rather than IQueryable<T>, so element type detection returned null and nothing was applied, leaving EF Core to raise FirstWithoutOrderByAndFilterWarning.

The two placement walks are now one predicate naming the operators the ordering has to precede, used both to find the source entity type and to insert the ordering. Aggregates and Single are excluded, since ordering them is pointless work, and snapshots assert they stay unordered.

Redundant order detection walked into combined sequences

FindSource followed the first argument of any static method whose source looked enumerable, which includes Concat, Union, Join and friends. Ordering applied to one side was reported as redundant even though the default ordering is never applied to the combined result, so the advice to remove it was wrong.

Inherited ordering could not see non public properties

CreateForDerivedType looked the property up with the default binding flags, which only match public members. Ordering configured on a mapped non public property failed to inherit with Property 'SortOrder' not found on derived type 'Derived', even though the derived type does have it.

Performance

Both are compile time only, since QueryCompilationStarting sits behind EF Core's compiled query cache.

• IncludeOrderingApplicator rebuilt the entire query tree on every compilation even when there was no Include to touch. The chain analysis already reports whether one is present, so it now runs first and gates the visit. The options extension is also resolved once instead of once each by RequiredOrder and RedundantOrder.
• Dropped the two element type caches. Both guard a fast path of a few type comparisons that is cheaper than the dictionary probe, and they pinned every type they were handed for the life of the process, which stops a collectible load context unloading. The Include method cache stays, since MakeGenericMethod is genuinely expensive. OrderByClause also no longer holds the Queryable and Enumerable method tables in static fields after resolving its eight methods.

Notes

The second fix changes behaviour: Take now returns different rows than before, deterministic ones, and queries that previously tripped EF Core's row limiting and first without ordering warnings no longer do. That may warrant a major version bump rather than a patch.

Two things left alone deliberately. Configuration.cache still pins entity types for the process lifetime, since it is the config lookup on every compilation and has to be a real cache. RequiredOrder.validated still keys by DbContext type, so the same context type used with different UseDefaultOrderBy options would share a validation result; the tests already declare a separate context type per option combination, so the design was left as is.

Verification

122 tests pass. Each fix has tests, and for the last two I confirmed they are regression tests by reverting the source fix and watching them fail.