fix(registry): refuse a name-only match the receiver chain contradicts

[CaptainMittens]

What does this PR do?

A Swift project's URLSession.shared.data bound to its own PickedFile.data,
UserDefaults.standard.string to a DTO's string, and JSONEncoder().encode
to a model's encode. "Who calls this?" then answers with calls that never
happened.

The cause is that the two name-only resolution strategies match on the final
segment alone. A dotted callee whose first segment starts upper-case names a
type — URLSession, Calendar, JSONEncoder — and that receiver chain is
evidence the scorers were discarding.

receiver_chain_admits() now requires the candidate's own parent segment to
appear somewhere in that chain:

callee	candidate	in the chain?	outcome
URLSession.shared.data	HomeboxUI.PickedFile.data	PickedFile — no	refused
Calendar.utcGregorian.startOfDayUTC	AuthDTOs.Calendar.startOfDayUTC	Calendar — yes	kept

Three shapes pass through untouched, so ordinary code is unaffected:

• a callee with no separator, which has no chain to judge;
• a lower-case root, which names a value whose declared type the chain does
  not show — vm.load, http.Get, os.path.join;
• a name in capitals with an underscore, which is a constant holding a value
  rather than a type. This carve-out is measured, not guessed: without it the
  gate refused ISO_4217_URL.lower → builtins.str.lower, which is correct.
  JSON and URL carry no underscore and stay guarded.

The gate applies only at the two name-only exits of resolve_name_lookup.
import_map, same_module and qualified_suffix already carry real evidence
and are left alone.

Language agnostic by design — the registry holds no language, and every language
that writes receiver chains gains the same protection.

Why the confidence score could not do this instead

The clearest errors were the highest-confidence ones. Swift's import map is
empty (system frameworks are never indexed nodes, so cbm_pxc_build_import_map
drops them), and the 0.5 penalty in resolve_name_lookup only applies when an
import map exists. So the worst calls kept the full 0.75. A threshold would have
cut correct edges and left these.

A "never point a call at a Variable" guard is also wrong: Variable is a legal
target on purpose (cbm_label_is_registry_symbol), one project here has 645 such
edges and another 984, and Variable nodes carry no type property, so nothing
in the graph separates a callable variable from stored Data.

Fixes #1893

Validation

Reproduce-first. With the fix reverted and the five tests kept, exactly the two
refusal tests fail and the three guard tests already pass — which is the point,
since a guard test that only passes with the change proves nothing:

registry_receiver_chain_refuses_library_unique_name_issue1893   FAIL tests/test_pipeline.c:8799: r.qualified_name is not NULL
registry_receiver_chain_refuses_library_suffix_match_issue1893  FAIL tests/test_pipeline.c:8814: r.qualified_name is not NULL
registry_receiver_chain_keeps_project_extension_issue1893       PASS
registry_receiver_chain_ignores_lowercase_root_issue1893        PASS
registry_receiver_chain_ignores_bare_name_issue1893             PASS

Blast radius, measured on three real codebases

The gate changes resolution for every language, so I counted what it refuses
rather than reasoning about it. Read from live graphs, applying the rule to every
unique_name and suffix_match edge:

project	languages	unique_name	refused	suffix_match	refused
homebox-interface	Swift	5300	278 (5.2%)	3827	295 (7.7%)
homebox	Go, TypeScript, Python	4933	14 (0.3%)	3348	2 (0.06%)
Home_Server	Python, shell	190	2 (1.1%)	37	0

The Swift project is where the bug lives and it moves most. The Go/TypeScript
project loses 16 edges out of 8281 name-only ones — 0.2% — because its import
map already resolves most calls before the gate is reached.

I read every non-Swift refusal by hand. They are all wrong bindings the gate
should refuse:

Date.now            -> homebox.scripts.asc-build-state.now
JSON.parse          -> homebox.frontend.lib.datelib.datelib.parse
Array.from          -> homebox.backend.pkgs.mailer.test-mailer-template.from
Promise.all         -> homebox.docs...starlightChangelogs.versions.all
Object.entries      -> homebox.frontend.pages.checkbooks.[id].entries
Body.Close          -> homebox.backend.internal.data.ent.Close
Path(__file__).resolve -> Home_Server.homelab.scripts.withsecret.resolve

import_map, same_module and qualified_suffix counts are unchanged
everywhere, since the gate never runs on those paths.

Suites

Suite	Result
pipeline	260 passed, 0 failed (255 before, plus the 5 new)
full make -f Makefile.cbm test	7635 passed, 28 failed, 8 skipped

The 28 failures are all in tests/test_cli.c (client install/uninstall) and are
pre-existing in my environment. Measured rather than assumed: origin/main here
runs 7630 passed / 28 failed, and this branch adds exactly the 5 new tests with
the same 28 failures in the same file. If they are green on your runners they
are environmental on mine.

Lint: make -f Makefile.cbm lint-cppcheck and lint-no-suppress both exit 0.
clang-format wants no change on any line this PR adds. I could not run
clang-tidy locally — it is not in my toolchain — so that one is unverified on
my side.

Checklist

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

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

[DeusData]

Approved, and I want to be explicit that this cleared a bar most changes of its shape do not.

There is a standing position here that a precision fix restricting receiver resolution globally is the wrong shape — suppressors are written as per-language helpers gated on the file language, and all three existing ones (Perl, TS/JS, cross-language suffix) are built that way. This PR is global. It was accepted anyway, on four things it does that the usual version of this change does not:

The upstream strategies are provably untouched. I checked rather than took it: resolve_import_map and resolve_same_module both run before resolve_name_lookup and win when they hit, so gating only the two name-only exits leaves same_module, import_map and qualified_suffix alone. That matters more than it looks — the specific casualty this rule exists to prevent is a Go receiver method, which carries a flat package QN and resolves only through the same_module suffix branch. Your gate never reaches it.

You measured the blast radius instead of arguing it. Three real codebases, split by language, with every non-Swift refusal read by hand. 16 edges out of 8281 name-only ones on the Go/TypeScript project is the number that settles this, and Date.now → asc-build-state.now, Body.Close → ent.Close, Promise.all → starlightChangelogs.versions.all are all plainly wrong bindings. A blocked high-confidence match does not vanish here, it just stops being invented.

Your reason for going global is factually right. cbm_registry_resolve takes no language parameter — I confirmed the signature. The per-language alternative is a post-resolution suppressor at the pass_calls.c / pass_parallel.c seam, and that would silently miss any other consumer of the resolver.

And you ruled out the cheaper fix with evidence. "The clearest errors were the highest-confidence ones" is the sentence that closes off the threshold approach: Swift's import map is empty, so the 0.5 penalty never applies and the worst edges kept the full 0.75. A confidence cut would have removed correct edges and left these.

Two smaller things worth naming

Your guard tests pass without the change, deliberately. "A guard test that only passes with the change proves nothing" is exactly right, and showing the reverted run with 2 FAIL / 3 PASS is the clearest way to demonstrate a gate that refuses the right things without over-refusing. Most reproduce-first evidence stops at the failing half.

The ISO_4217_URL carve-out is measured, not guessed. Excluding capitals-with-underscore because the gate otherwise refused ISO_4217_URL.lower → builtins.str.lower, while noting JSON and URL carry no underscore and stay guarded, is the kind of boundary that only comes from running it.

Status

Cleared, reviewed, approved. main was briefly broken earlier today and repaired by #1993; your green predates that, so I will re-run this against current main before merging. Nothing needed from you.

Thank you — this is the most carefully evidenced call-resolution change we have had.