Import edges die when a same-stem foreign sibling exists (Python, PowerShell, Zig, Rust, Pascal, Elixir, bash)

[filipechagas]

Problem

A same-stem sibling file of any language silently kills import-edge resolution for several languages: id disambiguation salts both file nodes (lead_py_lead, lead_ts_lead) while the import edge still targets the bare alias (lead), which now dangles. Everything downstream loses the edge — including Python's module-arm member-call resolution. A stray lead.md next to lead.rs is enough.

Measured affected (repros in upstream PR Graphify-Labs#2503, commits 4–5):

• Python (import lead / module-arm calls)
• PowerShell, Zig, Rust, Pascal, Elixir (stem-named imports)
• bash — a different shape: graphify/symbol_resolution.py re-derives ids by path formula after disambiguation, producing a duplicate dangling edge next to the correct one (and the same stale ids break its source-backed calls edges under collision)

Audited and NOT vulnerable: TS/JS (stamp target_file), C++/ObjC (header_remaps), Julia/Fortran/Verilog (importer-scoped target nodes), Dart (own stub nodes), Ruby/PHP (no file-targeting import edges).

Fix (reference implementation exists)

Upstream PR Graphify-Labs#2503 fixes this on upstream v8:

• Python: stamp the target_file hint the disambiguator already reads (the Phantom self-cycles: same-basename cross-extension re-exports (X.ts → ./X.mjs) collapse to one node Graphify-Labs/graphify#1814 mechanism) — an import in language X can only mean a language-X file, so the hint is unambiguous.
• Five stem-named languages: one central language table in the hint pass (_hint_import_targets); it only picks among salted variants of an id the edge already named, so collision-free corpora are bit-identical.
• bash: make symbol_resolution.py consult post-disambiguation ids (_file_nids_by_path) so its duplicate dedupes away.

This issue tracks porting that work (2503 commits 4–5) to the fork's v8, adapted to the fork's diverged tree.

Open question inherited from the audit

Go's import edge dangles without any collision (go_pkg_example_com_m_lead unresolved with and without go.mod) — possibly a fixture problem, possibly a real Go resolution gap. Unasserted either way; needs its own investigation.

Acceptance criteria

• Per-language collision tests (control + collided corpus) through the public extract() seam; red demonstrated against unfixed fork code
• Collision-free corpora bit-identical (parity evidence)
• No target_file hint leaks into graph.json
• Full suite green vs the current fork baseline (4087/36 at cec9cdd); counts reconciled

Blocked by

None. Sibling: #24 (receiver-type index scoping — same porting pass, 2503 commits 2–3).

[filipechagas]

Closed by PR #34 (merge commit d724156), porting upstream 2503 commits 4-5. Gate evidence: red-first; 4107/36 at head, independently reproduced. Parity: bit-identical (md5-matched) serialized graph on a collision-free 7-language corpus; under collision 7 dangling import edges -> 0 with bash's duplicate deduping away. Go's collision-free dangle remains open as this issue's recorded question.