fix(memory): build the RaBitQ index on demand and use it on the vector path

[shuishui313]

Summary

• Add ensureRabitqIndex(): builds/rebuilds on demand using the existing
  shouldRebuildRabitq() thresholds (10-vector floor, 20% drift), with a 60s
  throttle, a process-level disable when the WASM backend is unavailable, and
  binding to the source dbPath and dimensions.
• Wire it into all three search entry points: the sql.js pre-filter, the bridge
  vector path, and embeddings_rabitq_search, which no longer needs a manual
  build first.
• bridgeSearchBruteForceCosine() reranks RaBitQ's Hamming candidates with the
  same exact cosine, reading only the candidate rows by primary key; any failure
  falls back to the unchanged exhaustive scan.

Closes #4203.

Behavior

The exhaustive path pre-ranks LIMIT 10000, so on corpora larger than 10k the
indexed path no longer drops rows outside that window. This is an intended
improvement, not a ranking change. The bridge hybrid path (bridgeSearchEntries,
1000-row BM25+cosine) is untouched, so describeBackend() continues to report
brute-force cosine there.

Test plan

• __tests__/issue-4203-rabitq-auto-build.test.ts — 6 tests against a real
  sqlite store: build on demand, exact rerank, no rebuild per search,
  below-floor negative control, indexed-vs-exhaustive parity within the
  candidate window, recall + exact rerank on a 60-row corpus above the
  window (>=80% top-5 recall).
• Regression: memory-bridge suite, issue-3311, memory-active-row-visibility,
  issue-2922-hnsw-status-honesty — 9 files / 32 tests pass.
• tsc --noEmit on @claude-flow/cli: no new errors (14 pre-existing, none
  in touched files).

Risks

• Corpora >10k rows: the indexed path no longer hides rows the pre-rank window
  dropped. A rowCount > 10000 fallback can be added if strict parity is
  required.
• Index freshness remains bounded by the 20% drift policy; rows written inside
  the window are not candidates until a rebuild fires.
• rabitq.meta.json is written but never read, so a new process rebuilds on its
  first search. Restoring from meta needs version/dims/sourcePath/count
  validation and is out of scope.
• memory-bridge.ts already exceeds 500 lines; the change is additive rather
  than a refactor.

[shuishui313]

CI is waiting for approval as a first-time contribution. Could a maintainer approve the workflow run? thanks.
The results:
Local results: 6 new tests plus the memory regression suite (9 files / 32 tests) pass;
tsc --noEmit reports no new errors (14 pre-existing, none in touched files).

[ruvnet]

Reviewed the diff for correctness against the PR description's own claims (not just taking them at face value):

• Throttle/staleness interaction (rabitq-index.ts, AUTO_BUILD_RETRY_MS): lastAutoBuildAttempt is set unconditionally before the build attempt, so a failed build (non-WASM-unavailable error) does delay the next retry by the full 60s. Matches documented behavior, not a hidden bug.
• Process-scoped disable: autoBuildDisabled is a module-level let — resets on restart as expected.
• Concurrency: traced the throttle's check-then-set and the build's rabitqInitializing guard — both synchronous with no await in between, so no real race under Node's single-threaded model. searchRabitq() is async but contains no actual await, so a concurrent rebuild can't interleave mid-search.
• shouldRebuildRabitq() wiring: correctly invoked with a fresh indexable-entry count each window against the last real build's vectorCount; 10-vector floor and 20%-drift logic both exercised as documented.
• LIMIT 10000 claim: verified accurate. It pre-exists unchanged in the exhaustive scan; the new RaBitQ path chunks candidate lookups by 500 instead (no 10k cap), so the claimed behavior difference is real. bridgeSearchEntries's hybrid path is untouched — confirmed no diff there.
• Mergeability: a raw two-dot diff against main looks noisy (shows feat(memory,providers): tag filter for memory list/search, explicit-provider precedence, Ollama default model #3526's already-merged tag-filter code as "removed" since this branch forked before that landed), but a true three-way merge is clean with zero conflicts — only 4 commits behind / 2 ahead, not stale the way a couple of other open PRs are right now.

Minor gap: no test exercises the WASM-unavailable permanent-disable path or genuinely concurrent ensureRabitqIndex() calls — correctness there is established analytically above, but a follow-up test would be good.

No blocking issues. CI is running now (just approved the pending first-contribution workflow runs) — will merge once green.