fix(registry): restrict same-module and unique-name suffix matches on receivers

[sahil-mangla]

Description

This PR tightens the call-resolution core in the registry to prevent false-positive CALLS edge resolutions when dealing with qualified receivers, improving precision across all supported languages.

Changes

• Restricted resolve_same_module on receivers: The resolve_same_module strategy now validates the receiver prefix. It will correctly resolve self-receivers (self.get), exact module prefixes (proj.pkg.service.get), and last-segment namespace matches (service.get). It actively rejects resolving to local functions when the receiver is clearly unrelated (e.g., axios.get or _get_store().get), preventing spurious edges to same-named functions within the current module.
• Restricted resolve_name_lookup for qualified callees: Added a qn_ends_with_qualified check. If a callee name is explicitly qualified (e.g., contains . or ::), the resolution candidate's qualified name must properly terminate with that exact qualification (unless the candidate is explicitly labeled as a Method), preventing cross-namespace leakage on generic method names.

Impact

• Precision vs Recall: This change heavily favors precision, eliminating wide blast-radius false positives on common method names (like get, add, update) when invoked on unrelated imported or delegated receiver objects.
• Testing: Added regression tests for resolve_same_module_only_on_self_receiver and verified the full test suite runs cleanly.

[DeusData]

Thanks for taking on the receiver false-positive problem. The exact head is security-clean and DCO passes, but it is not correct enough to merge:

1. Every full Unix/macOS/Windows test job fails deterministically at cp_enum_method_java: valid Java enum calls such as d.label() and d.isWeekend() become unresolved. This existing convergence guard must remain green.
2. The blanket Method/type-like-parent exemption preserves the main false-positive class: an unrelated axios.get can still resolve through unique_name when the sole candidate is labeled Method. The new negative test uses a Function, so it does not exercise that common path.
3. Add direct coverage for the unique and multi-candidate paths, imported receivers, . and :: qualification, and candidates labeled Method.
4. Use the canonical cbm_label_is_type_like() policy rather than duplicating the label set in the registry.

The precision goal is valid, but the registry currently lacks enough receiver/language/type evidence for this global heuristic: it is simultaneously too strict for valid Java dispatch and too permissive for unrelated Method candidates. Please redesign the suppression around receiver-aware evidence, preserve the Java enum convergence test, and update the PR's “full suite clean” statement after the complete matrix is actually green.