C#: `find_implementations` returns non-implementing types and misses a real implementation in large multi-project solution

[skohanowski]

Summary

On a large private multi-project C#/.NET repository, find_implementations
returns a materially incorrect implementation set for an interface.

The result contains multiple types that do not implement the requested
interface, while also omitting at least one type that does implement it.

This reproduces after a completely clean cold index with only the primary Git
checkout tracked. Git worktrees are not involved.

Environment

• OS: Windows 11 x64
• Repository: private, large multi-project .NET solution
• Gortex version: v0.64.3 (56a1c29)
• Clean store created from scratch
• Only primary checkout tracked
• Index state: fresh
• No linked worktrees tracked or composed during this test

Reproduction

1. Remove the existing Gortex store.
2. Start Gortex against a clean store.
3. Track only the primary repository checkout.
4. Wait until the repository reports fresh.
5. Select an interface with multiple real implementations.
6. Query its implementations using the normal implementation-query tool.
7. Compare every returned type against the C# source/compiler-visible type declarations.

Actual result

The returned set contains:

• multiple types which do not implement the queried interface;
• at least one legitimate implementation is absent.

The incorrect relationships are returned as normal implementation results.
The response does not provide a warning sufficient to tell a caller that these
specific edges are heuristic or potentially false.

The same result was reproduced on two independent cold indexes.

Expected result

find_implementations should either:

1. return only semantically valid implementations, or
2. clearly expose provenance/confidence for inferred relationships so callers can distinguish compiler/LSP-confirmed implementations from heuristic ones.

A real implementation should not be omitted.

Why this matters

For an MCP coding agent, find_implementations is commonly used for impact
analysis and refactoring. False positive implementation relationships combined
with false negatives can cause both unnecessary changes and missed changes.

Additional notes

This was initially discovered during a broader worktree evaluation. To exclude
persistent-store contamination, the entire correctness test was repeated from
a clean cold index before any worktree was activated. The result reproduced.

I can create a minimal anonymized C# fixture if useful.