bug(indexer): C# variables is hardcoded to [] — no fields or locals are parsed, breaking receiver-type inference for method calls #1525

tools/languages/csharp.py:160 (also :106, :180)

variables is returned as a hardcoded empty list, and CSHARP_QUERIES contains no variables entry at all — no field declaration and no local declaration is ever parsed.

Reproduction

$ .venv/bin/python -c "
from codegraphcontext.tools.tree_sitter_parser import TreeSitterParser
from codegraphcontext.tools.languages.csharp import CSharpTreeSitterParser
import tempfile, pathlib
p = pathlib.Path(tempfile.mkdtemp())/'a.cs'
p.write_text('class A {\n  private int _f = 1;\n  void M() { int total = 0; }\n}\n')
print(CSharpTreeSitterParser(TreeSitterParser('c_sharp')).parse(str(p))['variables'])
"
[]

Confirmed across all 17 C# fixture files: variables == 0 everywhere.

Impact

Two distinct losses:

1. writer.py:300 writes zero Variable nodes for C#, so fields and locals are absent from the graph — find_code cannot locate them and no Class-[:CONTAINS]->Variable edge exists.
2. More consequentially, resolution/calls.py (lines 1979, 2006, 2033, 2300) uses local-variable declarations to infer a receiver's type when resolving method calls. With no variable data, var svc = new UserService(); svc.Save(); cannot resolve Save to UserService.Save, so C# method calls fall back to name-only heuristics.

Suggested fix

Add a variables query covering field_declaration and local_declaration_statement (with the variable_declaration/variable_declarator nesting), and populate the key instead of hardcoding []. c.py:114-122 is a reasonable template.

_{Reproduced with the snippet above and confirmed against the C# fixtures.}