fix(cpp-lsp): use direct includes to disambiguate receiver targets

[knewstimek]

Direct C++ member calls through a reference or pointer can resolve to a mirrored definition even when the caller directly includes the intended header. In the synthetic regression, adding a duplicate header and implementation reduces the intended method's callers from three to one: UseRef and UsePtr move to the mirrored method while AcquireAgain remains.

This change ranks fallback receiver candidates using the current module and top-level literal quoted relative header includes, preserves namespace boundaries, and requires a unique best candidate. Exact invocation span and source origin carry ambiguity into CALLS materialization so later textual fallback does not select a tied receiver.

The synthetic unit regression checks registration order, module-prefix collisions and qualified namespaces. Seven real stdio MCP cases cover baseline, duplicate definitions, an explicit mirrored include, ambiguous includes, absent include evidence, a qualified namespace and a namespace mismatch. Two cases exercise the parallel extraction path.

Validation: Windows LLVM-MinGW build and seven real MCP regression cases passed. Changed C formatting, Python syntax and git diff --check passed. Full repository lint success is not claimed: prior attempts encountered existing formatting violations and Windows tool execution failures. Linux and sanitizer checks remain unverified.

Run python tests/test_cpp_duplicate_calls.py <binary>.

Scope: top-level literal quoted relative .h/.hpp/.hh/.hxx includes. Compiler search paths, parent traversal, macro/conditional/transitive includes and compiler-equivalent visibility are outside this change. It does not implement factory-return inference or guarantee correctness for every C++ receiver. Existing stored graphs require reparsing affected callers to receive corrected edges.

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