fix(registry): drop suffix_match CALLS across language boundaries

[rudi193-cmd]

Summary

• Fixes get_architecture hotspots report inflated fan_in that contradicts actual graph in-degree (same-name collision across languages) #725: when two same-named symbols exist in different languages, suffix_match no longer attaches CALLS (and therefore hotspot fan_in) to the wrong language.
• unique_name (candidates == 1) is left to Python stdlib import binds to a same-named TypeScript function (cross-language, strategy=unique_name) — poisons hotspots and Louvain clusters #1572. Receiver-type disambiguation among same-language candidates is Call resolution picks the wrong target (or none) for common method names in a Kotlin monorepo #1555.
• JS / TS / TSX are treated as one family so .ts calling .tsx is not dropped.

Test plan

• scripts/test.sh --suites registry — cross_language_suffix_match_drops_py_vs_js PASS
• scripts/test.sh --suites pipeline — pipeline_cross_language_same_name_does_not_share_calls_issue725 PASS (251 passed)
• Maintainer: confirm this does not collide with the Python stdlib import binds to a same-named TypeScript function (cross-language, strategy=unique_name) — poisons hotspots and Louvain clusters #1572 unique_name language-boundary work

Made with Cursor

[DeusData]

Thank you — and the scoping here is the part I want to call out. You fixed the cross-language case and explicitly left unique_name to #1572 and receiver-type disambiguation to #1555, rather than sweeping all three into one diff. That is exactly right for a graph-correctness change: each of those has a different failure mode and deserves to fail its own test.

Treating JS/TS/TSX as one family is the detail most people would have missed. Dropping a .ts → .tsx call to fix a Python-vs-JS collision would have traded one wrong answer for another, and silently — which in this project counts as a correctness regression, not a tradeoff.

Fair warning on timing: our CI is badly backed up tonight (8 runs queued, no runners allocating) because we are pushing a v0.10.5 that fixes a batch of install and startup blockers. Your PR is queued behind that. It is a graph-quality fix rather than an operability blocker, so it will land after the release rather than in it — no reflection on the change, just the order the queue forces.

I will review it properly once the backlog clears.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.