feat(jvm): resolve Java/Kotlin imports by fully-qualified name

[arttttt]

Summary

• Wrap top-level declarations of .kt / .java files in an implicit namespace node carrying the file's package, so a class Bar in package com.example.foo is indexed with qualifiedName com.example.foo::Bar.
• New resolveJvmImport strategy (gated to Java/Kotlin, imports-kind refs only) looks up FQNs through the qualifiedName index — import com.example.foo.Bar now resolves by package, not by filename, with confidence 0.95.
• Fix hasAnyPossibleMatch pre-filter so it doesn't strip JVM FQNs (com.example.foo.Bar) before resolution gets a chance — the previous logic only consulted the first segment.

Motivation

Java's existing filesystem-based path lookup (import com.example.Foo → com/example/Foo.java) works only because Java enforces class-name = filename. Kotlin doesn't — Bar can live in Models.kt, Utils.kt, or any file under package com.example. Top-level functions and extension functions have no class to name a file after at all. The fallback path (name-matcher) finds some match for collisions but cannot disambiguate same-name classes across packages — the central failure mode in multi-module Spring / Android codebases (see the mall / halo notes in the dynamic-dispatch playbook).

This change makes imports edges land on the exact target the package declares, which feeds callers / callees / context precision and lays groundwork for binding-precise Dagger2 / Hilt resolution later.

What's covered

Case	Test
package com.example.foo → class qualifiedName com.example.foo::Bar	extraction.test.ts (Kotlin / Java)
Single-segment package	extraction.test.ts
No package → qualifiedName unchanged (regression guard)	extraction.test.ts
FQN lookup of class import	resolution.test.ts (unit, mocked context)
Top-level function import	unit + integration
Cross-language Kotlin importing a Java class	unit + integration
Name collision across packages — each caller resolves to ITS Bar	unit + integration
Wildcard com.example.* deliberately falls through to name-matcher	unit
Non-JVM languages skip the strategy entirely	unit
Non-imports reference kinds skip the strategy	unit
imports edge end-to-end, filename ≠ class name	frameworks-integration.test.ts

19 new tests; all existing Kotlin (8), Java (2), Spring (3), pr19 (33), symbol-lookup (9), resolution (23), frameworks (86), frameworks-integration (8) suites stay green.

Out of scope

• Wildcard imports (import com.example.*) — name-matcher still handles these.
• Aliased imports (import com.example.Bar as Baz) — the Kotlin extractor doesn't currently surface the alias; orthogonal to this PR.
• Companion-object property imports, typealias chains — left for a follow-up.

[arttttt]

Before/after validation on two Kotlin/Java repos

Indexed both repos with main-build and this branch, compared SQLite snapshots. Probe-only (deterministic), no agent A/B — adoption-gap caveat from the dispatch playbook still applies.

Coverage of in-project import statements

Repo	Files	In-project import statements¹	main resolved	branch resolved	Coverage
spring-petclinic/spring-petclinic-kotlin	38 .kt	16	0	16	0% → 100%
macrozheng/mall	524 .java	893	0	860	0% → 96.3%

¹ Ground truth: grep -c "^import <project-prefix>\." src --include="*.{kt,java}".

The mall result is the more meaningful one — it's the central failure mode this PR addresses: multi-module Maven where filenames don't sit at com/macro/mall/Foo.java paths, so the existing filesystem-based Java lookup misses them entirely.

Collision disambiguation (mall)

mall has aggressive name collisions — MyBatis-generated examples:

Name	Variants across packages
Criteria	76
Criterion	76
GeneratedCriteria	76
OmsOrderDetail	2 (admin dto vs portal domain)

Sample of 5 collision-targeted imports — each caller-package resolved to the correct target-package (no cross-package leak):

portal.controller  → portal.domain::OmsOrderDetail   ✓
service.impl       → bo::AdminUserDetails             ✓
portal.service     → portal.domain::OmsOrderDetail   ✓
portal.dao         → portal.domain::OmsOrderDetail   ✓
dao (admin)        → dto::OmsOrderDetail              ✓

Spot-check 20 random resolved imports on mall: 20 / 20 plausibly correct on package-flow inspection (mapper→model, service→mapper, controller→dto/common.api).

Delta accounting — no edge inflation

Edge counts per kind on mall before/after (this is the part I want a sanity check on — the only thing that should change is contains for the new namespace nodes):

kind	main	branch	Δ
contains	20 047	20 571	+524 (= namespaces, one per packaged file)
references	11 036	11 036	0
calls	10 974	10 974	0
imports	2 878	2 878	0 (same count, target shifted)
instantiates	550	550	0
extends / implements	94 / 50	94 / 50	0
heuristic interface-impl	310	310	0
total	45 629	46 153	+524

imports edge count doesn't change — what changes is target: it shifts from a stub import-node to the actual project class/interface. The dynamic-dispatch synthesizer (interface-impl, 310 edges — matches the playbook's reported mall number) is unchanged.

Concrete codegraph_node improvement

For interface VisitRepository in petclinic-kotlin:

• main: Trail is empty — graph has zero incoming edges to the interface (calls go to its methods, not the interface). Agent would Read files to find usages.
• branch: Trail surfaces 4 incoming sources (OwnerController.kt, VisitController.kt, and their tests), letting the agent answer "who uses VisitRepository?" without Read.

Caveat

This is a deterministic-correctness measurement. It does not, by itself, demonstrate an agent A/B win — see the trace-adoption discussion in docs/benchmarks/call-sequence-analysis.md. The mechanism here improves callers / context / trace precision unconditionally; whether that converts to fewer agent Reads is adoption-gated.

Side note (not a regression in this PR)

While running these probes I noticed the CLI's post-index report (X nodes, Y edges in Zms) undercounts edges — it sums only extraction-phase results (src/extraction/index.ts:836), so resolution-phase + synthesizer edges aren't included. On mall, CLI reports 20 047 edges while the DB has 45 629. Pre-existing on main, orthogonal to this PR — flagging as worth a separate fix.

---

Repro: https://github.com/spring-petclinic/spring-petclinic-kotlin + https://github.com/macrozheng/mall cloned at depth=1, indexed with the same builds. Raw metrics in /tmp/eval/{petclinic,mall}-{main,feat}.txt locally — happy to attach if useful.

[arttttt]

Followup on the CLI-undercount note from the previous comment — opened a separate fix: #413.

That PR is off main (not stacked on this one — the bug is pre-existing, unrelated to FQN imports). It snapshots (nodes, edges) before/after the full indexAll pipeline so the post-index summary reports the true totals, including resolution + synthesizer edges. Concrete impact on macrozheng/mall: CLI was reporting 20 047 edges, actual graph had 45 629.

Regression test included (__tests__/integration/full-pipeline.test.ts — verified to fail without the fix, pass with it). Self-contained scope: only indexAll is touched; indexFiles and sync use different fields and weren't affected.