Focus extraction hybrid pre-search queries

[sentry-junior]

Passive extraction pre-searched existing memories with the full user+tool transcript. That made hybrid retrieval less accurate and more expensive: embeddings and FTS ran over tool dumps and long session text instead of durable user evidence.

Current behavior

• processSession built the pre-search query from every user message and tool result before extraction.
• The completed-run projection prepends prior public-thread messages as ambient context authority, then appends this turn's run entries (packages/junior/src/chat/plugins/task-runner.ts).
• searchMemories already runs parallel vector + lexical legs and fuses ranks with RRF (packages/junior-memory/src/store.ts, ranking.ts).
• Recent lexical perf work kept that hybrid contract: perf(memory): remove structured identifier matching #1227, perf(memory): optimize lexical search #1233, perf(memory): bound lexical ranking candidates #1242.
• perf(memory): defer lexical recall until needed #1244 explored skipping lexical on automatic recall when any in-threshold vector hit exists. That path does not fix extraction and weakens exact/token recall.

Gap

• Extraction needs nearby existing memories for skip/supersede context.
• The retrieval query should include this turn's instructions and ambient thread context, but not raw tool dumps.
• Hybrid RRF performs well when each leg is a bounded top-k index probe, not when the query is a whole transcript or tool payload.

Impact

• Worse candidate quality for passive extraction skip/dedup decisions
• Unnecessary embedding + FTS cost on every completed session with tool output
• Pressure to optimize by dropping a hybrid leg instead of fixing the query

Prior art

• Supabase hybrid search: independent top-k full-text and vector CTEs, then RRF over short lists — https://supabase.com/docs/guides/ai/hybrid-search
• ParadeDB hybrid manual: keep lexical and vector separate, fuse ranks, do not blend raw scores — https://www.paradedb.com/blog/hybrid-search-in-postgresql-the-missing-manual
• Conversational RAG query rewrite / condense-question before retrieval (LangChain ConversationalRetrievalChain family)
• Multi-query rewrite and HyDE-style expansion for hard retrieval cases

Proposal

Requested design implemented in #1246:

1. Keep hybrid RRF for both searchMemories and recallMemories (no skip lexical if any vector hit).
2. For extraction pre-search, query from this turn's run-actor instructions + ambient thread context (not tool dumps), capped around 1.5k chars, instructions first then leftover budget for context.
3. Keep each retrieval leg bounded; tighten lexical rank candidates to a small hybrid window (hundreds, not thousands).
4. Leave the full run transcript available to the extraction model; only the retrieval query is curated.
5. Document selection rules in code comments so later sources (e.g. compact tool summaries / Luna rewrite) can be added deliberately.

[sentry-junior]

Follow-up recommendation for tool results:

• Do not add raw stdout, JSON, stack traces, or complete tool payloads to the retrieval query.
• If tool-derived context proves necessary, use a small fast rewrite model (Luna is suitable) to turn successful tool results into a few concise factual search phrases.
• Append those phrases under the existing query budget, then run the same hybrid vector + lexical RRF search.
• Keep raw tool results in the extraction transcript only.

This is intentionally deferred from #1246: the current deterministic baseline uses turn instructions + ambient thread context. Add the rewrite step only with evidence that tool-heavy turns miss existing memories or create duplicates.