fix(resolution): resolve calls to object-literal namespace members (#1573)

[colbymchenry]

Fixes #1573. Thanks @IAliceBobI — the report had the root cause exactly right, and the fix sits one layer up from the suggested spot (resolution rather than the container-kind set), for the reason below.

What was wrong

Methods of an exported object-literal constant — export const api = { call() {…}, get: () => {…} } used as a module's API surface — never received a call edge from api.call(), same-file or through an import. The members are extracted as plain functions with bare qualified names (call, not api::call) sitting inside the constant's source extent, so:

• the Container::member lookup the class-shaped kinds use (Cross-file static method calls (ClassName.staticMethod()) are dropped: calls edge mis-promoted to instantiates #825) bails on kind constant, and even with constant added to that set there is no api::call to find;
• the declared-type inference for imported singleton instances (TypeScript: calls through an imported singleton instance resolve to the exported constant instead of the class method #1292) finds no type in a literal and falls back to the constant edge;
• the same-file strategies only consider classes and method kinds, so the call resolved to nothing at all.

Net effect: callers / impact reported zero for methods called from everywhere, with no boundary warning because nothing about obj.method() looks dynamic.

What this does

Adds one helper that resolves a member by containment — a node named member whose source range lies inside the value's range, in the value's own file — and uses it from both halves:

• Import path: when the imported value is a constant/variable, the literal member is tried right after the Container::member lookup and before the TypeScript: calls through an imported singleton instance resolve to the exported constant instead of the class method #1292 instance inference, so the cross-file edge lands on the method instead of the constant.
• Same-file path: a same-file constant/variable receiver (TS/JS family only) is checked before the class-name strategies.

Precision rules, all tested: calls accept callable kinds only; a declaration nested inside another member's body is not a member; nothing outside the value's range can donate a match — a same-named top-level function, or a method returned by a factory the value merely holds — so those cases keep today's behavior rather than guessing. Class statics (C.s()) and non-literal values are untouched.

Extraction and qualified names are deliberately left alone: changing how literal members are named would have to be mirrored in the native kernel byte-for-byte, and the resolver-side lookup is contained and language-gated.

Tests

• The issue's repro end-to-end: sameFileCallers and crossFileCaller are both callers of m; a decoy m in a third file gets none; the C.s() static control resolves exactly as before; crossFileCaller no longer has a calls edge to the constant.
• Arrow-property and method members both resolve; a function call() nested inside get's body is never taken for api.call().
• A value holding a factory's result (const obj = makeObj()) with a same-named top-level m in the file: no false attribution, existing behavior kept.
• The two positive tests fail on main; the control passes both ways, as a guard should.
• Full suite: 189 files, 3181 passed / 9 skipped.

With the built CLI on the issue's a.ts/b.ts: codegraph callers m → 2 callers (sameFileCallers, crossFileCaller); callers s unchanged; edges sameFileCallers -> m (0.85) and crossFileCaller -> m (import, 0.9), none to obj.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LxZj6W6Y1SHXwvpT3uwJpK