feat(csharp): constructors become graph nodes so DI wiring is visible

[NiSHoW]

_CSHARP_CONFIG lists only method_declaration in function_types, so a C#
constructor is not a graph node. Its parameters are therefore never walked by
the C#-specific parameter_type pass, and constructor-injected dependencies —
the dominant DI idiom in ASP.NET Core — leave no trace in the graph. Calls made
inside a constructor body are also attributed to the class rather than to the
constructor.

This adds constructor_declaration to function_types and
function_boundary_types, mirroring what _JAVA_CONFIG already does. In the C#
grammar constructor_declaration shares method_declaration's name and
parameters fields, so the generic walker and the C#-specific parameter_type
pass handle it unchanged; returns is absent on constructors and already
guarded. No other language is affected — the change is two entries in the C#
LanguageConfig.

Static constructors are covered for free. Not covered, and noted as follow-ups
in the code comment: destructor_declaration, and C#12 primary constructors
(their parameters live on class_declaration).

Effect on real codebases

Measured on two production ASP.NET Core repositories:

	constructor nodes	references[parameter_type] edges	of which to a type in the corpus
~2.2k-node repo	59	95	26

Those 26 edges are the dependency wiring — controller -> IService,
service -> DbContext — that the graph previously could not see at all.

Tests

tests/test_csharp_type_resolution.py::test_csharp_constructor_node_and_parameter_type_edge
asserts the constructor node exists, that its class owns it via a method
edge, and that an injected parameter type produces a
references[parameter_type] edge.

Full suite green (711 passed locally; the single failure on my machine,
test_extract.py::test_collect_files_skips_hidden, reproduces on an unmodified
v8 checkout and is a pre-existing Windows-only baseline failure).

🤖 Generated with Claude Code

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

---

Graphify review — findings

Treats C# constructor_declaration as a function type and function boundary in _CSHARP_CONFIG, so constructors become nodes owned by their class via a method edge and their injected parameter types emit references[parameter_type] edges (making DI wiring like controller→IBusinessContext visible). Destructors and C#12 primary constructors remain uncovered. Adds test_csharp_constructor_node_and_parameter_type_edge covering the constructor node, its method edge, and the parameter-type reference.

No blocking issues surfaced. 3 lower-confidence candidates did not survive cross-model review.

Analysis details — impact, health, verification

Impact & health

Graphify review

Impact — 1753 functions depend on the 268 functions this change touches.

Health — this change adds coupling hotspots:

• new: extract() — 521 callers, 43 callees
• new: _rebuild_code() — 113 callers, 50 callees
• new: extract_js() — 85 callers, 4 callees
• new: extract_xaml() — 19 callers, 17 callees
• new: dispatch_command() — 2 callers, 123 callees
• new: _get_extractor() — 26 callers, 6 callees
• new: run_pipeline() — 8 callers, 13 callees
• new: collect_files() — 17 callers, 6 callees
• …and 24 more — each is listed as a finding

Verification — 1753 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: 1588 function(s) in the blast radius were not formally verified this run

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