fix(jvm): resolve mixed Java/Kotlin callgraph edges

[nguyentamdat]

Summary

• infer JVM namespaces from src/main/java, src/main/kotlin, src/test/java, and src/test/kotlin roots for Java/Kotlin files
• preserve inferred namespace metadata in LSP definition cache entries so same-package JVM definitions survive cross-file filtering
• compare textual callees by leaf method name when applying LSP overrides, including the parallel lsp_idx path
• add a mixed Java/Kotlin regression that asserts strategy: lsp edges for Java -> Kotlin and Kotlin -> Java calls

Verification

• make -f Makefile.cbm test -> 5726 passed

Notes

Split out from the original bundled branch so this PR now contains only the JVM callgraph fix. The low-RAM indexing change is now separate in #685.

[DeusData]

Huge thanks for opening this PR and for the work you put into it.

The maintainer shop is currently full, so this may sit for a bit before it gets a proper review. We will come back to this as soon as possible with real feedback; I wanted to make sure it did not sit unacknowledged in the meantime.

[DeusData]

Thank you — the root cause is real and the fix uses the correct convention: the declared package is JVM ground truth, and mixed src/main/java + src/main/kotlin roots genuinely can't be joined by path-derived module QNs. Your red-first test (asserting strategy:lsp both directions AND absence of the weaker suffix strategy) is exactly how we like guards written, and splitting the low-RAM change into #685 was appreciated. One question before merge, not a blocker: the cbm_pipeline_lsp_target_node tail-match fallback applies to all languages, not just JVM — ambiguity returns NULL and the full suite is green, so the residual risk is a single wrong-module tail coincidence in a non-JVM language. Would you gate it to JVM languages, or do you have a case where the global fallback recovers real edges elsewhere? Happy either way with a one-line rationale.

---

Update: to get this into the next release, if we don't hear back on the gating question in the next couple of days we'll default to gating the tail-match fallback to JVM languages in a small follow-up on top of your branch and merge — with your commits landing as-is and full credit. If you have a case where the global fallback recovers real edges, just say so and we'll merge it ungated instead.

[DeusData]

Thank you — the root cause was real and your fix used the correct convention: the declared package is JVM ground truth, and your red-first test (asserting strategy:lsp both directions AND the absence of the weaker suffix strategy) is exactly how we like guards written. We carried it over the line with one addition per the review thread: the new tail-match fallbacks are now gated to JVM languages (rationale: unique Class.method leaf matching is safe under JVM class-per-file package semantics; elsewhere one wrong-module coincidence would fabricate an edge), with a guard test for the gate itself. Merged as 5f6461e (PR #818) with you credited as co-author. Splitting the low-RAM change into #685 earlier was appreciated — that one stays open on its own merits. Thanks again!

[nguyentamdat]

Thanks for carrying this over the line and for preserving the credit. JVM-only gating for the tail-match fallback makes sense to me: the fallback was intended to recover declared-package/class-method drift in Java/Kotlin, and I don’t have a concrete non-JVM case that needs the global behavior. Appreciate the clear rationale and the extra guard test.