Python: module-scope dict member calls can resolve to unrelated project methods

[zyyyyynnn]

Defect

When a Python module declares a module-scope dictionary (or other built-in collection) and calls methods on it (such as dict.get), unresolved method calls can fall through to bare-name method matching and fabricate calls edges to unrelated project classes that happen to declare a same-named method (e.g. LRUCache.get).

Repro

# settings.py
DEFAULTS = {"answer": "42"}

def read_setting(name):
    return DEFAULTS.get(name, None)

# cache.py
class LRUCache:
    def __init__(self):
        self._store = {}

    def get(self, key):
        return self._store.get(key)

$ codegraph callers get --limit 500 --json
{
  "symbol": "get",
  "callers": [
    { "name": "read_setting", "kind": "function", "filePath": "settings.py", "startLine": 4 }
  ]
}

read_setting in settings.py never imports or references LRUCache, but DEFAULTS.get() is incorrectly attributed to LRUCache.get.

Impact on Circular Dependency Analysis

GraphQueryManager.getFileDependencies walks resolved call/reference edges. When a false call edge is created across files, it introduces a false file dependency. On projects with a one-way import structure, this can report hundreds of phantom cycles (e.g. 136 reported cycles vs 1 genuine import cycle).

Scope & Relation

Discussed in #1566 (which addressed the TypeScript/JavaScript/TSX/ArkTS receiver resolution and conformance boundaries). This issue tracks extending similar receiver type inference and fallback boundaries to Python module-scope and instance member calls.