fix(registry): drop unique_name CALLS across language boundaries

[rudi193-cmd]

What does this PR do?

Follow-on to #1647 / #725. That PR dropped suffix_match CALLS when caller language ≠ target file language and left unique_name (candidates == 1) for this issue.

Python from unittest.mock import patch was binding to a unique TSX function patch via unique_name. The same helper now drops unique_name under the same rules: JS/TS/TSX stay one family; same_module / import_map / lsp_* stay.

Not in this PR: treating unittest.mock as an external specifier, IMPORTS-edge cleanup, #1555 receiver disambiguation, or #1128.

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (scripts/test.sh --suites registry,pipeline)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

Fixes #1572

Made with Cursor

[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.

[rudi193-cmd]

CI red on this PR is not the #1572 change.

Every failing shard dies on the same two tests, both predating this branch:

• cli_zero_argument_tool_never_reads_stdin_issue1359
• cli_stdin_args_gate_tracks_tool_schema_issue1359

list_projects now advertises pagination properties (offset, limit, include_details) on main. The #1359 gate treats “has properties” as “read stdin”, so cli list_projects is allowed to slurp stdin again and the tests that pinned “no properties / no stdin” go red. Sibling PRs off the same main (#1697, #1698, #1699) fail the same way.

Windows shard 2/2 also has an unrelated UTF-8 compare (raw-??????? content vs raw-Русский content in test_mcp.c).

scripts/test.sh --suites registry,pipeline was green locally for the unique_name tests. Not folding a #1359 schema-gate fix into this PR.

[DeusData]

Thank you for keeping this to the remaining unique_name cross-language case and explicitly excluding the adjacent import, receiver, and external-specifier work. That is the atomic boundary we need. The reported CI failures are also correctly left out of this diff rather than being bundled into the resolver fix. It is labeled as a high-priority graph-quality bug; the final review will verify same-language-family behavior and the negative cross-language cases before any merge decision.

[DeusData]

Picking this up, and doing the review that was promised on 18 August rather than leaving you waiting further. Sorry it took two weeks.

Your CI diagnosis was right, and there is now an extra fact you could not have had. Both of those tests — cli_zero_argument_tool_never_reads_stdin_issue1359 and cli_stdin_args_gate_tracks_tool_schema_issue1359 — pass on the current tree. I ran the full suite an hour ago: 7781 passed, 7 skipped, 0 failed, with both of those green. So the base defect you identified has since been fixed, and a rebase should clear your red without you touching anything.

One caveat before you rebase: main does not currently compile. Two changes landed the same type short-name index into type_registry.h and git merged them into duplicate struct members, so anything built against main right now fails. #1993 is the repair. Rebase after that lands, not before, or you will trade one unexplained red for another.

The review

The two things the 18 August note said would be verified before any merge decision — same-language-family behaviour, and the negative cross-language cases — both hold.

The production change is two lines: unique_name joins suffix_match in the strategy allowlist of the existing cbm_suppress_cross_language_suffix_match. Nothing else in registry.c moves. That is the right shape for this repo — a per-language-gated helper wired at both pass_calls.c and pass_parallel.c, rather than a restriction inside cbm_registry_resolve itself.

cross_language_unique_name_drops_py_vs_tsx asserts the cases that matter, including the ones a weaker suite would omit:

• suppressed in both directions (Python → .tsx, TSX → .py), not just the one from the issue
• not suppressed same-language
• same_module, import_map and lsp_direct all explicitly not suppressed
• JS/TS/TSX kept as one family, with .ts and .js callers of a .tsx target both asserted

That third bullet is the one I care most about, and you tested it. Every existing guard in this file deliberately preserves same_module, because a blocked high-confidence match does not disappear — it demotes into suffix_match, which picks a winner by import distance project-wide. A guard that gated same_module off could lose a correct edge and mint a wrong one in the same step. Yours cannot.

What actually holds it up

Not this PR's quality. It belongs to the call-resolution cluster — #1128, #1324, #1386, this one, #1766 — and there is a standing decision that they are judged against one shared census rather than one at a time. #1128 is the most global member, since it changes strategies inside cbm_registry_resolve while the others add suppressors downstream; whichever of them lands first shifts the baseline and makes the rest unjudgeable on their own numbers.

So this will not merge in isolation, and that is a sequencing constraint rather than a verdict on the change. I would rather tell you that plainly than let it sit silently for another fortnight.

Thank you for holding the scope where you did — excluding the import-edge cleanup, the receiver disambiguation and the external-specifier question was the right call, and it is why this one was quick to read.