Add CRAG-lite corrective retrieval around the knowledge search tool

[RuneLind]

Phase 1 of the corrective-retrieval work: after a copilot-sdk bot calls Huginn's search_knowledge MCP tool, judge the results and — if they're weak — do one bounded corrective re-query before the model sees them. Off by default. Plan: ../mimir/plans/huginn-muninn-corrective-rag.md.

Today the bot's own judgement is the only "retrieval evaluator" — if a search returns junk, the model just copes. This adds a CRAG-style judge-and-requery step, consuming the Phase-0 corrective signal Huginn now emits (bestScore, per-result confidenceBand, retryHints, noConfidentResults, min_relevance — Huginn PR #36).

Mechanism (copilot-sdk connector only): the connector registers a Copilot SDK onPostToolUse hook that intercepts each search_knowledge result before the model sees it (applyCorrectiveRetrieval → runCorrectiveRetrieval). Claude-CLI bots run the MCP tool in their own process and can't be intercepted this way — left to Phase 3 (prompt-level guidance); the asymmetry is documented. When the toggle is off the hook isn't registered → byte-identical to before.

Two grader modes (knowledge-grader.ts):

• "signal" — the default; no model call, ~0ms for confident searches. Reads the cheap signal Huginn already emits (a *Weak match …* / *No confident match …* footer, or a "No results found" body) and, when present, re-queries with the broaderQuery / narrowerQuery from Huginn's own retryHints. A weak search costs ~one extra HTTP call; a fully uneventful check emits no trace span.
• "haiku" — opt-in (correctiveRetrieval.grader: "haiku" / CORRECTIVE_RETRIEVAL_GRADER=haiku). A slimmed awaiting Haiku call that also reads the result snippets and can propose a semantic rewrite / a better collection. The result text is digested to the top hits' titles + bands + a short body prefix first, so it's ~3–5s per search rather than ~11s. Fail-soft: any Haiku error → correct (no change).

On a non-correct verdict (corrective-retrieval.ts): re-query Huginn's /api/search with rerank=true (so the re-query's bands are trustworthy), strip the now-obsolete *Weak match* footer from the prior result, merge + dedupe the fresh hits by collection/doc_id (parsed from the rendered result text), append an inline [corrective retrieval — re-query #N: …] note. Hard cap 1 retry (configurable to 2), never recursive.

Tracing: knowledge_grade (attrs: mode, verdicts, finalVerdict, …) + knowledge_requery (attrs: query, collection) spans synthesized under the tool span; a corrective chip on the parent tool span in the dashboard waterfall.

Config: per-bot correctiveRetrieval block in config.json ({ enabled?, retryBudget?: 1|2, grader?: "signal"|"haiku" }), CORRECTIVE_RETRIEVAL_ENABLED / CORRECTIVE_RETRIEVAL_BUDGET / CORRECTIVE_RETRIEVAL_GRADER global defaults, CORRECTIVE_RETRIEVAL_DISABLED=1 kill-switch. Off by default.

Testing

• Unit tests — signal grader (confident → no-op, weak footer → re-query with hint, related-terms-only → no re-query, budget 2 doesn't loop, "No results" body), Haiku grader (verdict parsing, fail-soft, result digesting), orchestrator (retry/merge/dedupe, budget exhaustion/clamp, re-query errors, footer-hint fallback, collection redirect, graderMode in metadata), search client (rendering, doc-id extraction, footer parsing, fetch + non-2xx), trace-span planner, connector hook helpers. bun run test green; tsc --noEmit clean.
• Manual end-to-end against a running Copilot-SDK bot + Huginn — enable correctiveRetrieval (signal mode), ask a question whose first search Huginn flags weak, confirm a knowledge_requery span appears and the bot answers from the merged set; confirm a confident search adds no knowledge_grade span and no latency. Validated once in "haiku" mode (the trace screenshot in the PR thread — grader took ~11s, which is why signal is now the default).
• E2E — n/a

Notes

• Depends on the Phase-0 contract — currently on Huginn PR Refactor: extract shared Knowledge API client #36 / branch phase0-corrective-signal, not yet on Huginn main. The signal grader leans on Huginn's *Weak match* / *No confident match* footer + retryHints, which that branch adds.
• A reranked: false flag on the /api/search response is a noted Huginn-side follow-up (coordinated with the Huginn peer).
• Known limitation: a corrective re-query hits /api/search directly, so it isn't constrained by the per-bot ALLOWED_COLLECTIONS the MCP adapter applies when no collection is specified in the original call (it does respect a collection passed in the original call). Collection-scoping the re-query is a possible follow-up.