fix(ts): resolve new_expression constructor calls

[hopstreax]

Summary

Fixes #3116.

TypeScript/JavaScript new_expression nodes were already included in call_types, but walk_calls looked for the callee using call_function_field="function".

Tree-sitter JS/TS exposes the constructor of new_expression through the constructor field, so new Foo() was silently dropped while normal function and static calls worked.

This adds a narrow fallback to read constructor when the generic callee lookup returns None for a new_expression.

Changes

• Resolve new Foo() as a calls edge.
• Preserve existing member-expression resolution for new pkg.Foo().
• Apply consistently to JS, TS, and TSX.
• Add regression coverage for:
  • TypeScript in-file constructor calls
  • TypeScript cross-file constructor calls
  • JavaScript constructor calls
  • TSX constructor calls
  • member constructor new pkg.Foo()

Validation

• 5 passed — new regression suite
• 44 passed — related language/member-call suites
• 201 passed, 4 skipped — tests/test_extract.py
• The 4 skips are the pre-existing Windows temp-path failure.

No unrelated production code was changed.

[graphify-labs]

Graphify reviewed this change.

Looks safe to merge — no coupling regressions and no blocking issues, checked against the code graph (not a self-assessment).

Formal verification. No changes could be formally verified in this run.

---

Graphify review — findings

Emits calls edges for new Foo(...) constructor calls in JS/TS/TSX by falling back to the constructor field in _extract_generic when the configured call_function_field yields no callee, since tree-sitter exposes new_expression callees there rather than under function. Member constructors (new pkg.Foo()) resolve as member calls with receiver, and cross-file constructor calls resolve to the imported class.

No blocking issues surfaced.

Analysis details — impact, health, verification

Impact & health

Graphify review

Impact — 629 functions depend on the 209 functions this change touches.

Health — this change adds coupling hotspots:

• new: _extract_generic() — 18 callers, 24 callees
• new: extract_xaml() — 19 callers, 17 callees
• new: extract_js() — 85 callers, 3 callees
• new: extract_objc() — 27 callers, 9 callees
• new: extract_julia() — 17 callers, 7 callees
• new: extract_cpp() — 27 callers, 3 callees
• new: extract_vue() — 10 callers, 6 callees
• new: walk() — 1 callers, 56 callees
• …and 8 more — each is listed as a finding

Verification — 629 functions in the blast radius were not formally verified this run (proofs are advisory here).

Gate & verification

graphify gate

PASS — objectively clean (no health regressions, tests not run — proofs not run this pass (advisory)). Grounded, not self-assessed.

Advisory (not blocking):

• verification_scope: 569 function(s) in the blast radius were not formally verified this run

Formal verification

Could not verify: Could not verify \_extract\_generic.

The verifier did not have enough to check \_extract\_generic, so it is saying so rather than guessing. No false assurance is the whole point.

Guarantee: No guarantee either way, this is an honest abstention, not a pass.

Note: Reason: parameter `path` is annotated `Path` — outside the synthesizable primitive/collection set

· 16 more finding(s) on lines outside this diff (see the check run).