perf(adapter): skip op_search relevance projection when caller supplied order, fold search detection into find partition

The find pipeline previously walked queries twice: once for the partition
(vector / adapter-filter / other) and again via `extractSearchQueries` to
project a `_relevance` SELECT and ORDER BY. With FULLTEXT MATCH that
means the relevance MATCH is compiled and evaluated a second time.

Pick up search queries in the existing single-pass partition loop and
skip the relevance projection entirely when the caller already supplied
an explicit order — the Documents trait auto-appends `$sequence` as a
tiebreaker, so anything richer than a lone `$sequence` is caller-driven
and would be silently overridden by relevance order otherwise.

`extractSearchQueries` is kept as a protected method for adapter overrides
but is no longer called from `find`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: abnegate

src/Database/Adapter/SQL.php

@@ -1182,14 +1182,17 @@ public function find(Document $collection, array $queries = [], ?int $limit = 25
 
         // Single pass partitioning: pull vector queries out for ORDER BY and
         // detect aggregation/join shape in the same walk. Each Method::value
-        // is checked once per query rather than three times.
+        // is checked once per query rather than three times. Search queries
+        // are picked up here too so we don't need a second pass via
+        // `extractSearchQueries` later in this method.
         // Defer the defensive `clone` until we know the query path will mutate
         // the Query objects (joins or aggregations-with-joins). The vast
         // majority of finds take neither path and don't need a per-query
         // clone allocation.
         $vectorQueries = [];
         $otherQueries = [];
         $adapterFilterQueries = [];
+        $searchQueries = [];
         $hasAggregation = false;
         $hasJoins = false;
 
@@ -1210,6 +1213,10 @@ public function find(Document $collection, array $queries = [], ?int $limit = 25
 
             $otherQueries[] = $query;
 
+            if ($method === Method::Search) {
+                $searchQueries[] = $query;
+            }
+
             if ($method->isAggregate() || $method === Method::GroupBy) {
                 $hasAggregation = true;
             }
@@ -1423,9 +1430,22 @@ public function find(Document $collection, array $queries = [], ?int $limit = 25
             }
         }
 
-        // Full-text search relevance scoring
-        $searchQueries = $this->extractSearchQueries($queries);
-        if (! empty($searchQueries)) {
+        // Full-text search relevance scoring.
+        //
+        // Skip the second MATCH compilation (and its ORDER BY) when the caller
+        // already asked for an explicit order. The Documents trait auto-appends
+        // '$sequence' as a tiebreaker, so a `$orderAttributes === ['$sequence']`
+        // signal — with no entries before it — means "caller did not specify
+        // an order" and is the only case where we should auto-order by
+        // relevance. Anything else (multiple entries, or a leading attribute
+        // other than $sequence) means the caller has an explicit order and
+        // relevance ordering would silently override it.
+        $callerSuppliedOrder = ! (
+            count($orderAttributes) === 0
+            || (count($orderAttributes) === 1 && $orderAttributes[0] === '$sequence')
+        );
+
+        if (! empty($searchQueries) && ! $callerSuppliedOrder) {
             $builder->select(['*']);
             foreach ($searchQueries as $searchQuery) {
                 $relevanceRaw = $this->getSearchRelevanceRaw($searchQuery, $alias);