Call resolution picks the wrong target (or none) for common method names in a Kotlin monorepo #1555

Environment: v0.10.2, Windows 11, daemon mode, --mode full index. Kotlin (Spring) + TypeScript monorepo, ~20.6k nodes / ~101.7k edges.

Symptom

trace_path(mode=calls) resolves call hops by name, and for method names shared by many symbols it either picks a wrong target or silently returns nothing:

1. Wrong target across modules. A use-case method calls repository.inserir(...) where the receiver is the domain port CompromissoRepository (constructor-injected). The trace lists the callee as JooqFeriadoRepository.inserir — an implementation of a different port in a different bounded context that happens to share the method name. The correct implementation is identifiable in the same graph via the OVERRIDE edge (JooqCompromissoRepository.inserir → CompromissoRepository.inserir), so the information needed to disambiguate exists.

2. Missing callers. The same use-case method (executar, also a very common name in this codebase) shows callers_total: 0, although a controller in the same module calls it directly one file away. Unique names resolve perfectly — an extension function with 4 call sites returned exactly those 4 callers.

Suggestion

When candidates > 1 for a hop:

• prefer the declared receiver/parameter type (present in source and, for implementations, derivable from OVERRIDE/INHERITS), and/or
• surface the ambiguity in trace_path output — the CALLS edge already stores candidates and confidence, but the trace renders an ambiguous hop with the same look as an exact one (related: trace_path format=json drops include_evidence strategy and confidence #1542, which asks for strategy/confidence in format=json).

Agents treat a trace as evidence; a wrong hop that looks identical to a right hop is worse than no hop.