fix(registry): recognize C# lower-case type keywords in receiver_chain_admits

[AmirF194]

What does this PR do?

receiver_chain_admits() (src/pipeline/registry.c) fast-admits a lower-case-rooted receiver chain as a value rather than a type. That's correct for Go, Python and Swift (vm.load, http.Get, os.path.join), but C# spells its built-in types as lower-case keywords (int, string, bool, ...), so a static call like int.TryParse(...) skips the chain-consistency check entirely and can fabricate a CALLS edge to any unrelated method sharing the same name (#2121).

Fix: a closed set of C# type keywords is checked only when the receiver root is lower-case; anything not in that set still fast-admits exactly as before, so other languages' lower-case value roots are unaffected.

Fixes #2121

What does this PR do NOT fix?

The issue's second example, Options.Create(new object()), no longer reproduces at HEAD: PR #1897 (merged 2026-09-04) already added the chain-consistency guard this PR extends, and it happens to cover that upper-case-rooted shape already.

How was this verified?

• Added registry_receiver_chain_refuses_lowercase_type_keyword_issue2121. Without the fix, ASSERT_NULL in that test trips because the fabricated edge still resolves; with the fix it's clean. Ran both ways in the same Docker image (ubuntu:24.04, ASan+UBSan test build).
• Reproduced the issue's own two-file C# example end to end with the built CLI (index_repository + trace_path): int.TryParse fabricates an edge to an unrelated TryParse on main; zero edges on this branch.
• Added a second test, registry_receiver_chain_keeps_type_keyword_when_chain_matches_issue2121, confirming the guard still resolves a real project type whose chain matches, so it isn't just refusing everything lower-case.
• Full pipeline suite (279 tests) green on this branch; cppcheck and clang-format --dry-run clean on the changed file. Not checked against the exact CI toolchain: local cppcheck was 2.13.0 and clang-format 18.1.3, CI pins 2.20.0 and clang-format-20.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[AmirF194]

Both red legs here (test-windows CLANG64 timing race, and the downstream shard-completeness failure that depends on it) are outside this diff, neither touches registry.c or test_pipeline.c. Been open a week with no look yet, let me know if anything's blocking review.

[DeusData]

Thank you for the C# keyword fix and negative controls. The current registry's lower-case receiver handling supports the reported gap. Review should preserve the C# keyword cases without admitting unrelated receiver names in other languages. We still need to attribute the Windows failure from its evidence; an unchanged Windows-specific file list alone would not prove it unrelated. The contribution is queued for that focused review.