The results of $vectorSearch come out sorted by 'vectorSearchScore'. If a $sort stage comes directly after $vectorSearch, and the sort criteria is by the vectorSearchScore, the sort should be able to be removed, as it should pass the documents in and out it in the same order.

The $sort that follows the $vectorSearch can come from being explicitly specified, or from desugaring of another stage that requires sorting like $setWindowFields. The optimizing code should not need to differentiate these cases, but both types should be tested for correctness.

Note: This optimization should only apply to single node environments, as $vectorSearch pipelines that have subsequent $sort stages are broken apart as a $vectorSearch on the shard nodes, with a $mergeCursors stage followed by the $sort on the merging (mongos) node. This part of the optimization will be handled separately, and is more generic as many pipelines (other than $search ones) in a sharded environment may have a $mergeCursors stage followed by a $sort.

Note: This optimization should only apply to pipelines where the $sort comes directly after the $vectorSearch stage. This optimization should be generalizable to cases where stages that do not affect the sort order of the documents come in-between the $vectorSearch and $sort, however there are some pre-requisites to tackle before we can implement this generalization, which will be handled in subsequent tickets.