feat(miner-rag): wire issue-centric RAG retrieval into a scoped MCP tool

[JSONbored]

This item is genuinely blocked, and this issue should say so plainly rather than pretend it's fully scoped.

The pure half is already handled separately: buildIssueRagQuery (src/review/issue-rag-wire.ts:24-38) composes a retrieval query from an issue's title/body/labels, and is explicitly marked "Intentionally pre-built and currently unreached: no miner-side issue-analysis caller exists yet (#2320)" (issue-rag-wire.ts:23). Its extraction to packages/gittensory-engine/ is filed and open separately as #4254 — that issue is a small, zero-risk move of the pure query-builder only, and does not need to wait for anything here.

What actually blocks "wire ... into a scoped MCP tool" is the retrieval backend itself: retrieveContext (src/review/rag.ts:488, with a metrics-wrapped variant retrieveContextWithMetrics at line 412) is Vectorize/D1-bound infrastructure that only exists server-side inside the hosted Worker. A local miner CLI or local MCP process cannot call it directly — there's no local equivalent, and reaching it means either a new authenticated hosted API round-trip, a local retrieval stack, or deferring RAG entirely for v1. That decision is tracked in #4258 and is explicitly unresolved as of this writing (open, three options laid out, no chosen direction). Building "the MCP tool" today would mean guessing at that decision.

Deliverables

• Blocked: do not start the actual MCP tool wiring until decision needed: how does a local miner reach RAG retrieval without a hosted round-trip? #4258 resolves how a local miner reaches RAG retrieval
• Once decision needed: how does a local miner reach RAG retrieval without a hosted round-trip? #4258 is decided, this issue (or its replacement, re-scoped to the chosen approach) wires a new MCP tool that: takes issue title/body/labels, builds the query via buildIssueRagQuery (importing from gittensory-engine once feat(engine): extract buildIssueRagQuery to gittensory-engine #4254 lands, not the current src/review/issue-rag-wire.ts location), retrieves context via whatever access path decision needed: how does a local miner reach RAG retrieval without a hosted round-trip? #4258 lands on, and returns results in the metadata-only shape the rest of the miner surfaces use
• Track feat(engine): extract buildIssueRagQuery to gittensory-engine #4254 (query-builder extraction) as a soft dependency for import path only — it can land independently and this issue should just pick up its new location when ready
• Re-scope or split this issue once decision needed: how does a local miner reach RAG retrieval without a hosted round-trip? #4258 lands, since the concrete deliverables here depend entirely on which of the three options in decision needed: how does a local miner reach RAG retrieval without a hosted round-trip? #4258 gets picked

References

• src/review/issue-rag-wire.ts:24-38 (buildIssueRagQuery, the pure query builder, feat(miner-rag): issue-centric RAG query builder (issue title/body → embeddable query text) #2320)
• src/review/issue-rag-wire.ts:23 ("currently unreached: no miner-side issue-analysis caller exists yet")
• src/review/rag.ts:488 (retrieveContext, the Vectorize/D1-bound backend that is not locally reachable)
• src/review/rag.ts:412 (retrieveContextWithMetrics)
• feat(engine): extract buildIssueRagQuery to gittensory-engine #4254 (extraction of buildIssueRagQuery to gittensory-engine — independent, unblocked, should land regardless)
• decision needed: how does a local miner reach RAG retrieval without a hosted round-trip? #4258 (open decision: how a local miner reaches RAG retrieval without a hosted round-trip — this issue is blocked on it)
• Wave 2 tracker 🧩 Wave 2 — Analyze, Plan, Create & Deploy (HELD tracker) #2353, Phase 2

[linear-code]

JSO-3280