fix: apply fusion weighting uniformly and recalibrate the exact-keyword floor

[benjaml4]

Addresses the confirmed remainder of #978 (post-correction).

As the reporter's follow-up established, BM25 scores are sigmoid-normalised before fusion — but the structural asymmetry stands: the BM25-only branch used the normalised score directly, bypassing bm25Weight, so keyword-only candidates (sigmoid floor 0.5) outranked semantic candidates capped at vectorWeight no matter how the weights were configured.

Two changes:

1. Uniform scoring — every candidate gets clamp01(max(v·vectorWeight + b·bm25Weight, keywordFloor), 0.1).
2. Floor recalibration — the exact-keyword floor's 0.75 threshold predates the sigmoid: 1/(1+e^(-raw/5)) reaches 0.75 at raw ≈ 5.5, which almost every FTS hit clears, so the floor (b·0.92 ≥ 0.69) quietly re-created the bypass on both branches. 0.95 corresponds to raw ≈ 14.7 — genuinely exceptional matches (identifiers, exact strings), preserving the floor's documented purpose of keeping those above minScore.

Observed effect on a 7,253-row store: queries with no relevant corpus content used to return unrelated keyword-only hits at floored confidence 0.85; they now score ~b·bm25Weight (≈0.28, below default minScore) and are suppressed, while on-topic queries are unaffected (verified before/after on the same store).

If you'd prefer the floor threshold configurable rather than a constant, happy to add a retrieval.keywordFloorThreshold option instead. An alternative worth considering longer-term is rank-based fusion (RRF) — which the comment above this code already names — as it sidesteps score-scale calibration entirely. tsc --noEmit clean.

[rwmjhb]

Reviewed head 2043eb9. Applying configured fusion weights uniformly is the right direction, but the new 0.95 keyword-floor policy introduces two retrieval blockers.

1. test/retriever-rerank-regression.mjs fails because a strong lexical/semantic candidate (vector 0.5006586, BM25 0.78) now fuses to about 0.5845, falls below minScore=0.6, and is removed before reranking.
2. BM25 graceful degradation is broken. With default bm25Weight=0.3, every BM25-only score below 0.95 is weighted below 0.285 and cannot pass the default minScore=0.3; the existing graceful-degradation test reproduces this with a 0.9 BM25 hit when vector search fails.

Please preserve configured weighting when both backends participate while renormalizing or using the surviving backend's score when one backend fails, and replace the universal floor with a calibrated/configurable exact-match signal that keeps existing strong lexical matches. Add boundary tests around the floor and keep both existing regressions green.

Requesting changes.

[rwmjhb]

Fresh recheck of 2043eb9: there have been no author commits or replies since the August 4 changes-requested review, and the retrieval regressions remain reproducible.

• node test/retriever-rerank-regression.mjs fails at the strong lexical-hit assertion: the expected result count is 1, but the new fusion/floor policy returns 0 before reranking.
• node --test test/retriever-graceful-degradation.test.mjs fails 2 of 8 tests, including the BM25-only fallback when vector search fails; the expected result count is 1, but weighting a surviving BM25 score by the default 0.3 removes it.

Please renormalize to the surviving backend when one search backend fails, and replace the universal 0.95 keyword floor with a calibrated/configurable exact-match rule that preserves existing strong lexical hits. Add boundary regressions before requesting re-review. The existing CHANGES_REQUESTED decision still applies.