fix(find): the hybrid legs rank inside the filter, and only the page is read

A hybrid find fuses a text leg and a semantic leg. The semantic leg already
walked only the metadata filter's universe. The text leg did not: it ranked
the WHOLE store, took the top `limit * 4`, read every one of those rows from
canonical, and only then intersected with the filter. On a large store with a
selective filter that is hundreds of rows read to return a handful — and a row
matching both the query and the filter, but sitting outside the store-wide
text prefix, was silently dropped. The same defect `find({ connected })`
carried before the graph-first law, one leg over.

Both legs now rank ids inside the universe and neither reads canonical. The
text leg goes through a new optional `getIdsForTextQueryWithin` door on
MetadataIndexProvider — the text twin of `filterIdsWithin`, so a native index
can intersect its postings before any string crosses the boundary; the
reference index implements it from its own posting-list merge, so the two
doors can never disagree, and a provider without it is served by the
whole-store answer intersected here. The fusion ranks shells, the page is cut
from them, and canonical is read once for exactly that page — with the row
rebuilt in full, so a hydrated row is indistinguishable from an eagerly-built
one (same flattened fields, same entity, same match visibility, same key
order). The eager forms of both legs stay for the search modes whose leg
output IS the answer.

Measured on the production recall shape (query + type list + `missing`
negation + excludeVFS, limit 60) the old order read 241 rows in two batches to
return one; the new order reads the page.

Pinned in tests/integration/find-hybrid-filter-before-hydrate.test.ts. The
oracle there is the pre-change pipeline itself, replayed on the same brain
through the same doors: where the filter does not truncate the text leg the
answer is identical — rows, order, scores, match visibility and row shape —
across hybrid + where, + type list + excludeVFS + a `missing` negation, +
connected, with and without offset. Where it does truncate, the correction is
held by name: the old order's text leg contributed nothing at all, the new one
returns the matching rows and paging reaches every one of them. The cost pins
read the engine's own counters: one batchGet of `limit` ids, the whole-store
text door never called, and what the text leg marshals bounded by the universe.

src/utils/metadataIndex.ts

@@ -1509,11 +1509,56 @@ export class MetadataIndexManager implements MetadataIndexProvider {
    * @returns Array of { id, matchCount } sorted by matchCount descending
    */
   async getIdsForTextQuery(query: string): Promise<Array<{ id: string; matchCount: number }>> {
+    return this.scoreTextQuery(query)
+  }
+
+  /**
+   * Score a text query over `ids` ONLY — the reference implementation of the
+   * optional `getIdsForTextQueryWithin` door (see
+   * {@link import('../plugin.js').MetadataIndexProvider}). The hybrid
+   * `find({ query, where })` path passes the metadata filter's universe here so
+   * the text leg ranks INSIDE that universe instead of ranking the whole store
+   * and discarding the rows the filter would have dropped.
+   *
+   * It answers from the same posting-list merge as {@link getIdsForTextQuery},
+   * with the candidate membership applied as each word's postings are counted,
+   * so the two doors can never disagree: the answer is exactly the whole-store
+   * answer restricted to `ids`, in the same order.
+   *
+   * @param query - Text query to search for.
+   * @param ids - Candidate entity ids; only these may appear in the answer.
+   * @returns Array of { id, matchCount } sorted by matchCount descending.
+   */
+  async getIdsForTextQueryWithin(
+    query: string,
+    ids: readonly string[]
+  ): Promise<Array<{ id: string; matchCount: number }>> {
+    if (ids.length === 0) return []
+    return this.scoreTextQuery(query, new Set(ids))
+  }
+
+  /**
+   * The one posting-list merge behind both text doors.
+   *
+   * Each query word contributes AT MOST one match per entity (a posting list
+   * can name an id more than once), and entities are ranked by how many of the
+   * query's words they matched. `within`, when given, restricts the count to
+   * those candidates — applied during the merge, so a restricted call never
+   * materializes a whole-store match map.
+   *
+   * @param query - Text query to search for.
+   * @param within - Optional candidate universe; absent = the whole store.
+   * @returns Array of { id, matchCount } sorted by matchCount descending.
+   */
+  private async scoreTextQuery(
+    query: string,
+    within?: ReadonlySet<string>
+  ): Promise<Array<{ id: string; matchCount: number }>> {
     const queryWords = this.tokenize(query)
     if (queryWords.length === 0) return []
 
-    // Get IDs for each word hash
-    const wordIdSets: Map<string, number>[] = []
+    // Count matches per entity, one word's postings at a time.
+    const matchCounts = new Map<string, number>()
     for (const word of queryWords) {
       const wordHash = this.hashWord(word)
       let ids: string[]
@@ -1529,19 +1574,12 @@ export class MetadataIndexManager implements MetadataIndexProvider {
           throw err
         }
       }
-      const idSet = new Map<string, number>()
+      // One count per (word, entity) — dedupe this word's postings first.
+      const counted = new Set<string>()
       for (const id of ids) {
-        idSet.set(id, 1)
-      }
-      wordIdSets.push(idSet)
-    }
-
-    if (wordIdSets.length === 0) return []
-
-    // Count matches per entity
-    const matchCounts = new Map<string, number>()
-    for (const idSet of wordIdSets) {
-      for (const [id] of idSet) {
+        if (counted.has(id)) continue
+        counted.add(id)
+        if (within && !within.has(id)) continue
         matchCounts.set(id, (matchCounts.get(id) || 0) + 1)
       }
     }