Add implicit ORDER BY Distance for VectorSearch translation

[roji]

Tiny follow-up to #38075.

VECTOR_SEARCH() results are inherently ordered by distance ascending. This adds the ordering implicitly during translation so users can compose with Take() without needing an explicit OrderBy(r => r.Distance).

Before:

ctx.VectorEntities
    .VectorSearch(e => e.Vector, similarTo: vector, "cosine")
    .OrderBy(e => e.Distance)  // required boilerplate
    .Take(3)
    .ToListAsync();

After:

ctx.VectorEntities
    .VectorSearch(e => e.Vector, similarTo: vector, "cosine")
    .Take(3)  // implicit ORDER BY Distance ASC
    .ToListAsync();

An explicit .OrderBy() or .OrderByDescending() still overrides the implicit ordering.

We could adopt a more low-level/conservative approach, saying that since SQL Server requires the explicit ORDER BY at the SQL level, we should continue requiring it at the LINQ level. However, we already add implicit orderings elsewhere (especially when transforming JSON arrays to resultsets with OPENJSON), and I don't see the point of having a mandatory, explicit gesture where we can save users the trouble.

[Copilot]

Pull request overview

This PR updates EFCore.SqlServer’s VectorSearch() translation to automatically apply ORDER BY Distance ASC, reflecting SQL Server’s VECTOR_SEARCH() natural ordering so that users can compose with Take() without adding boilerplate OrderBy(r => r.Distance).

Changes:

• Add an implicit ORDER BY Distance ASC to the translated VECTOR_SEARCH() query.
• Update SQL Server functional tests to remove redundant explicit OrderBy(Distance) calls.
• Update VectorSearch() XML docs to describe the new implicit ordering behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
test/EFCore.SqlServer.FunctionalTests/Query/Translations/VectorTranslationsSqlServerTest.cs	Removes explicit OrderBy(Distance) from existing VectorSearch tests while keeping ORDER BY in generated SQL baselines.
src/EFCore.SqlServer/Query/Internal/SqlServerQueryableMethodTranslatingExpressionVisitor.cs	Introduces a shared Distance column projection and appends an implicit ordering by that column.
src/EFCore.SqlServer/Extensions/SqlServerQueryableExtensions.cs	Updates API remarks to state results are implicitly ordered by distance ascending.

[roji]

@copilot address the above unresolved comments.

[Copilot]

@copilot address the above unresolved comments.

Done in e8af99c:

1. Renamed VectorSearch_project_entity_only_with_distance_filter_and_ordering → VectorSearch_project_entity_only_with_distance_filter since the ordering is now implicit.
2. Extended IsNaturallyOrdered in SqlServerQueryableMethodTranslatingExpressionVisitor to also recognize VECTOR_SEARCH ordering by Distance ASC as a natural ordering, consistent with how OpenJson ordering is handled. This prevents spurious Distinct-after-OrderBy warnings when composing with .Distinct().

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

[Copilot]

TranslateTake's VECTOR_SEARCH Skip/Take rewrite doesn't preserve multiple-Take semantics: if the query already has Limit (e.g. Skip(1).Take(5).Take(10)), this branch overwrites it and can return too many rows. Consider first applying the normal Take translation (so Limit becomes min(oldLimit, newLimit)), then use that effective Limit for both the inner TOP(existingOffset + effectiveLimit) and the outer FETCH, rather than using the new translation directly.

[Copilot]

Adding SelectExpression.SetOffset(...) introduces a new (public) API surface area (even with [EntityFrameworkInternal]). The repo tracks public API in EFCore.Relational.baseline.json, so this PR likely needs the corresponding baseline update to keep API validation passing.

Suggested change

	public void SetOffset(SqlExpression? sqlExpression)
	internal void SetOffset(SqlExpression? sqlExpression)