LEAN: graph-context + few-shot code translation/migration tools with project-level RLHF loop

## Summary

Design for a language-agnostic code translation/migration feature ("LEAN"): rather than hand-written pattern-matching/rule tables per language pair (brittle, doesn't scale across arbitrary migration pairs), use the existing code graph for structural context plus a small set of few-shot examples, with an LLM doing the actual translation. When a translation comes out wrong, the user adds a corrective example — building a project-level RLHF loop that improves accuracy for that specific codebase's migration over time, without retraining anything.

## Key design decisions (from prior design session)

- **Why not rule-based:** TOML-style explicit transformation rules were considered and rejected — "brittle and won't scale" across arbitrary language/framework migration pairs. An LLM given graph-derived structural context plus a handful of few-shot examples is more flexible, and the few-shot set is exactly the mechanism that lets users correct mistakes without code changes.
- **Language-agnostic:** the same 7 MCP tools work for any migration pair (e.g. one legacy language to another, one framework to another) — the graph-context + few-shot mechanism doesn't hardcode anything language-specific.
- **Phasing:** phases 1-4 are graph-only (no LLM involved at all — pure structural analysis: mapping, dependency discovery, scaffolding). LLM-assisted translation is deliberately deferred to phase 6, after the non-LLM groundwork is solid.

## Proposed MCP tools (7 total)

1. `migration_map` — map source-codebase structure to target-codebase equivalents using graph structure.
2. `migration_deps` — discover cross-file/cross-module dependencies that a migration must account for (analogous to `transitive_impact`, but migration-oriented).
3. `migration_scaffold` — generate target-side scaffolding (files/module structure) from the source graph.
4. `translate_symbol` — the LLM-assisted step (phase 6): translate one symbol at a time, using graph context + few-shot examples as the prompt's grounding.
5. `migration_validate` — validate translated output against expected structure/contracts.
6. (Two more tools referenced in the original design as part of the 7 total — names not fully captured in the saved session; worth revisiting the original design discussion or re-deriving during implementation planning.)

## Few-shot / RLHF loop mechanism

- A config format holds few-shot examples (source snippet → correct target snippet pairs) per project.
- When `translate_symbol`'s output is wrong, the user adds a corrective example to this config.
- Future `translate_symbol` calls for similar constructs include the growing example set as grounding — improving accuracy specifically for this codebase's migration, without any model fine-tuning.

## Open assumption (unvalidated, flag if wrong)

Assumes graph context (structural relationships: calls, inheritance, imports, etc.) provides sufficient information for accurate translation. If this proves insufficient in practice, deeper AST-level analysis (not just graph-level) may be needed as additional grounding for `translate_symbol`.

## Scope (proposed, not yet built)

1. Implement `migration_map`.
2. Implement `migration_deps`.
3. Implement `migration_scaffold`.
4. Implement `translate_symbol` (LLM-assisted, phase 6 — depends on 1-3 being solid first).
5. Implement `migration_validate`.
6. Build the few-shot examples config format (schema + storage location, likely `.infigraph/` scoped).
7. End-to-end test with one real migration pair to validate the graph-context-is-sufficient assumption above before investing further.

Start by revisiting the original design discussion and inspecting the existing MCP tool entry points and code-graph APIs; no implementation files or tests are named in the issue. Define the missing two tools, establish the phased graph-only scope, and validate one real migration pair before treating the graph-context assumption and few-shot configuration as complete.

Written by the indexing model from the issue text.