Resolve C# cross-file type references and extract enum/struct/record declarations

[TheFedaikin]

Summary

Adds a deterministic C# cross-file type-reference resolver so dangling inherits / implements
/ references edges re-point from no-source "shadow" stubs to their real definitions,
disambiguating same-named collisions (e.g. WeaponData defined in two namespaces) by the
referencing file's using directives + enclosing namespace. This is the C# counterpart to the
Java type-reference resolver (#1318).

Motivation

Cross-file C# type references resolve by bare name and fall back to a no-source shadow stub.
_rewire_unique_stub_nodes repairs that only when a name is globally unique; when two
namespaces define a same-named type it bails, so the edge stays stuck on the shadow node and
the real type is wrongly isolated. A using N; directive (plus the enclosing namespace) names
the scope precisely, so it disambiguates where bare-name matching cannot.

What changed

• graphify/extractors/csharp.py (new) — _resolve_csharp_type_references(per_file, paths,
  all_nodes, all_edges). Mirrors _resolve_java_type_references. Runs after id-disambiguation
  and _rewire_unique_stub_nodes, so it only handles the ambiguous remainder. Mutates
  nodes/edges in place and drops shadow stubs no edge references anymore.
• graphify/extract.py — wires the resolver into the cross-file pass, immediately after the
  Java type-reference resolution, behind a try/except that logs-and-skips so extraction never
  breaks. extract.py re-exports the resolver name (callers/imports unchanged).
• graphify/extract.py — _CSHARP_CONFIG — broadened class_types to also extract
  enum_declaration, struct_declaration, and record_declaration as type definitions (previously
  only class/interface). References to C# enums, structs, and records now get real definition
  nodes the resolver can re-point to.

Design notes

C# deltas from the Java resolver:

• A plain using N; is namespace-wide: a bare T is resolved by trying (N, T) for each open
  namespace and accepting only a unique hit — the god-node guardrail (ambiguous matches are
  refused, not picked arbitrarily).
• using X = N.T; is a single-type alias.
• global using … is normalized (the global prefix is stripped).
• using static N.T; is ignored (it imports members, not a namespace/type).
• The global namespace is keyed as the bare label.

Placement follows the extractor-split conventions (#1212): csharp.py imports shared
primitives (_read_text) from extractors.base, keeps the one-way import direction (extract.py
→ extractors/, never the reverse), and extract.py re-exports the moved name. The
config-driven extract_csharp extractor stays in extract.py for now — per
extractors/MIGRATION.md, config-driven languages can't be ported until the shared
_extract_generic core moves as its own coordinated batch; extractors/csharp.py is its
eventual home.

Tests

tests/test_csharp_type_resolution.py — 7 cases:

1. cross-file inherits resolves to the real def
2. same-name collision disambiguated by using
3. global using + global namespace
4. cross-namespace enum reference resolves
5. struct + record references resolve
6. ambiguity guardrail — two candidates → refuse, leave dangling (no wrong edge)
7. using X = N.T; alias resolution

Verification

• Full test suite passes; ruff lint and skillgen --check (the two pre-commit gates) clean.
• Behavior-neutral for non-C# languages — no extractor changes, and the new pass only runs on
  .cs inputs.
• Validated on a real Unity 6.3 C# fixture: same-named internal collisions re-point to the
  correct definition via using directives, while genuinely-external types (Unity/.NET)
  correctly stay unresolved.

[safishamsi]

Thanks @TheFedaikin — faithful C# port of the Java type-reference resolver, with the unique-hit guardrail correctly refusing ambiguous using matches. Landed on v8 in 76b6eab with your authorship. Verified: same-named types across namespaces resolve via using (shadow stub dropped), ambiguous using refuses without crashing, and enum/struct/record now extract. Known follow-up (noted in the commit): types in nested/multiple namespaces in one file aren't registered yet (fails safe). Reviewed alongside #1501/#1479 to confirm they compose. Closing as merged-by-port.