Reference dedup key doesn't include container context

[Widthdom]

Summary

The reference dedup key in ReferenceExtractor.cs:3065 is "{lineNumber}:{column}:{referenceKind}:{name}". It does not include ContainerKind or ContainerName. If two references to the same symbol occur at the same (line, column, kind) in different enclosing containers (e.g., two methods A.foo / B.foo on the same physical line in a copy-pasted region or via macro expansion), they collapse into one edge. The dedup mechanism cannot represent both A.foo → bar and B.foo → bar distinctly. The same pattern repeats across type-reference and JVM dedup sites.

Where

• src/CodeIndex/Indexer/References/ReferenceExtractor.cs:3065 (primary dedup key)
• src/CodeIndex/Indexer/References/ReferenceExtractor.TypeReferences.cs:26 (type-reference dedup)
• src/CodeIndex/Indexer/References/ReferenceExtractor.TypeReferences.cs:1079 (alternate signature)
• src/CodeIndex/Indexer/References/Support/JvmMethodReferenceExtractor.cs:225 (JVM method-call dedup)

Suggested approach

1. Audit all four dedup sites and confirm none include container context.
2. Extend the key to "{lineNumber}:{column}:{referenceKind}:{ContainerName}:{name}" (or include ContainerKind if needed for disambiguation).
3. Update every initializer of the seen HashSet to the new key shape.
4. Add a regression test with two same-named methods in different containers referring to the same target on the same line.
5. Validate DB backward compatibility — old reference rows that lacked container info should still load even if new writes have it.
6. Benchmark with a representative repo to confirm key-length increase doesn't hurt indexing throughput.

[Widthdom]

Work started on branch fix-issue2015-1934-1974.