fix(extract): isolate member-call resolvers and import edges from cross-language interference

CHANGELOG.md

@@ -45,6 +45,8 @@ Full release notes with details on each version: [GitHub Releases](https://githu
 ## 0.9.34 (2026-08-05)
 
 - Fix: C# receiver typing no longer drops a true call when a same-named variable is declared untypeably elsewhere in the method (#2472, thanks @JensD-git). Receiver types are now tracked per lexical declaration scope and resolved by the call's position, so a typed `static` local-function parameter keeps resolving even when an `out var` reuses the name in the enclosing body. This fixes a regression from 0.9.32 (#2346). Cross-method independence (#2299) and field-conflict poisoning are unchanged; an `out var` receiver itself remains untyped.
+- Fix: a member-call resolver no longer mints edges out of another language's data, which is two fixes. First, the Swift, Python and TypeScript resolvers consumed every raw call in the corpus: only the cpp, csharp, java and objc extractors stamp a `lang` tag, and those three languages carry none, so a TypeScript `Lead.search({})` reached the Python resolver's capitalized-receiver class arm and minted an EXTRACTED edge into a Python method with no TypeScript `Lead` anywhere in the corpus. Each now consumes only raw calls written in the source files it owns, a positive suffix filter that is closed by construction rather than a list of languages to exclude; the tagged languages keep matching on `lang`, because C++ and ObjC share `.h` and a suffix cannot tell their raw calls apart. Second, every receiver-type index is now scoped to its own sources — Java, C#, C++, Objective-C, Swift, TypeScript and Python — where each previously matched the receiver's declared type against class definitions written in ANY language. That cut both ways, so it is itself two fixes: a Java `Lead lead; lead.search()` bound to a Python `class Lead` at INFERRED, and a foreign class merely SHARING a short name pushed the single-definition guard to 2 and silently suppressed the correct same-language edge. Polyglot corpora therefore LOSE cross-language member-call edges that were always wrong — including some labelled EXTRACTED, the strongest confidence — and GAIN edges that a foreign short-name collision previously deleted. Single-language corpora are unaffected: every filter added here admits everything such a corpus contains. `.h` is scoped into both the C++ and the Objective-C index, because it routes to either extractor by content; the two are therefore isolated from every other language but not from each other. Python is scoped on both of its arms: a `ClassName.method()` receiver no longer binds to a class written in another language, and a `module.func()` receiver no longer resolves to a same-stem file that is not Python — `import lead` beside a `lead.ts` bound the call to a TypeScript function at EXTRACTED.
+- Fix: an `imports` edge no longer vanishes when any same-stem file sits beside its target, in Python, Rust, Zig, Elixir, PowerShell, Pascal and Bash. Each of these names an import's target by the imported file's bare stem id (`import lead` -> `lead`), which resolves only while that id is unique: add a `lead.md` and the two file nodes collide, so id-disambiguation salts them into `lead_py_lead` and `lead_md_lead` while the edge — keyed by the importer's own file rather than the target's — was left pointing at an id that no longer named anything, and was dropped along with everything downstream of it (Python's `module.func()` call resolution among them). These edges now stamp the `target_file` hint the disambiguator already accepts for this, so the salt lands on the right file; an import written in one language can only mean a file of that language, so the choice stays unambiguous whatever the collider is. An id claimed by more than one importable file of the same language is left dangling, as before, and a corpus with no collision is unchanged. Bash additionally emitted the edge twice under a collision — once correct, once dangling — because its second producer in `resolve_bash_source_edges` derives ids from the path after disambiguation has already renamed them; that pass now reads the ids as they actually stand, which also repairs the source-backed `calls` edges it resolves. TypeScript/JavaScript and C/C++/Objective-C already had equivalent protection; Julia, Fortran and Verilog target an importer-scoped node and were never exposed.
 - Fix: `graphify path` (and the MCP `shortest_path` tool) now respect edge direction by default instead of running on an undirected view, so a returned path no longer traverses edges backwards (#2487, thanks @luliaz0601). Direction is recovered from the stored `_src`/`_tgt` markers. Pass `--undirected` (CLI) or `undirected=true` (MCP) to search ignoring direction; when no directed path exists the command says so instead of silently returning a reversed one.
 - Fix: semantic extraction no longer aborts at merge with a `TypeError` when a hyperedge carries dict-shaped members (#2486, thanks @adminwat). Members are normalized to ids (or dropped with a warning) so a malformed hyperedge can no longer destroy a completed extraction.
 - Fix: `graphify merge-graphs` no longer drops hyperedges (#2484, thanks @sortakool, and @oleksii-tumanov for the approach in #1691). Hyperedge member ids and ids are now relabeled with the per-repo prefix, both inputs' hyperedges are unioned instead of one clobbering the other, and they are written to both the top-level and nested slots.