fix(cpp): emit instantiates edge for stack-allocation constructor syntax

[Dshuishui]

Summary

C++ stack-allocation syntax (ClassName var(args)) does not produce an
instantiates edge. Heap allocation (new ClassName(args)) works correctly
because new_expression is in INSTANTIATION_KINDS, but the stack form is
parsed by tree-sitter as a declaration node, which is never matched.

This fix adds a branch inside visitFunctionBody's body walker that detects
the pattern: a declaration node whose type field resolves to a class name
(via the existing normalizeCppReturnType primitive filter) and whose
init_declarator child contains an argument_list. When matched, an
instantiates unresolved reference is pushed — the same shape that
extractInstantiation produces for new_expression.

What's covered

• Calculator calc(0) → caller --[instantiates]--> Calculator ✓
• int x(5) → skipped (int is in CPP_NON_CLASS_RETURN) ✓
• Calculator calc = other → skipped (no argument_list in declarator) ✓

Known limitations

• Default constructor (Calculator calc;) — no init_declarator child,
  so no edge is emitted. Can be addressed in a follow-up.
• Brace initialization (Calculator calc{0}) — uses initializer_list
  rather than argument_list, not covered here.

Closes #1035

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4de2d123cb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve pointer qualifiers before emitting instantiations

Computing the target from only the declaration type field, and with a return-type normalizer that strips pointers/references and unwraps smart pointers, makes direct-initialized holders look like object construction. In C++ declarations such as Foo *p(nullptr), Foo &r(existing), or std::unique_ptr<Foo> p(nullptr), the later argument_list check still passes and this records instantiates Foo even though no Foo object is constructed at that declaration, polluting "what instantiates Foo" results in common pointer/RAII code. Please inspect the declarator shape and avoid unwrapping holder types for this extraction path.

Useful? React with 👍 / 👎.