test(goldens): the C# golden no longer matches what the parser produces — CALLS 12→7 drift hidden behind a passing test #1585

tests/fixtures/goldens/sample_project_csharp/ no longer matches what the current parser produces. Regenerating it on an unmodified main — no code change at all — yields:

nodes  Directory    6 ->   9   (+3)
nodes  File        15 ->  20   (+5)
nodes  Module       9 ->  12   (+3)

edges  CALLS       12 ->   7   (-5)
edges  CONTAINS   132 -> 140   (+8)
edges  IMPORTS     21 ->  32  (+11)

Reproduce with:

$ git stash            # ensure a clean tree
$ .venv/bin/python -m pytest \
    "tests/integration/test_parser_goldens.py::test_language_golden[sample_project_csharp]" \
    --update-goldens -q
$ git diff --numstat tests/fixtures/goldens/sample_project_csharp/

I confirmed the regeneration is deterministic — two consecutive runs produce byte-identical counts — so this is real drift, not nondeterminism.

Why it matters

The golden test still passes, so nothing surfaced this. But a golden that disagrees with the code is not a regression signal any more:

• CALLS 12 -> 7 is the concerning one. Five C# call edges that the golden says should exist are not being produced. Either they were lost by an earlier change and the golden was never updated, or the golden was recorded from a state the code never reached. Both are worth knowing.
• The File/Directory/Module growth suggests the fixture directory gained files after the golden was last recorded.

This also makes any C# parser PR hard to review: the raw golden diff mixes the author's change with accumulated drift. I hit exactly that in #1584 and had to regenerate on clean main first to isolate my own contribution.

Suggested fix

1. Regenerate the C# golden on main as a standalone commit, so the drift lands separately from any feature change.
2. Investigate the CALLS 12 -> 7 gap before doing so — if five call edges genuinely disappeared, refreshing the golden would bake the loss in permanently rather than fix it.
3. Worth checking the other language goldens the same way. I have not swept them, but nothing about this is C#-specific.

Related: a --update-goldens run across all projects is not safe for exactly this reason — it silently records whatever the current run produces. I hit that earlier and had to revert goldens for four languages I had not touched.