Cross-file CALLS edges resolve to Module node instead of caller Function node (v0.7.0)

[zambalee]

Bug Description

When a function in file A calls a function in file B, the resulting CALLS edge is attached
to the Module node (file-level) rather than the specific Function node that contains
the call. This makes "find callers of X" queries return a file path instead of a function
name.

Steps to Reproduce

1. Index a C project with cross-file function calls
2. Run:
   codebase-memory-mcp cli query_graph '{"project":"","query":
   "MATCH (caller)-[:CALLS]->(callee) WHERE callee.name='''lp_uart_init'''
   RETURN caller.name, caller.file_path"}'
3. caller.name returns the file path (e.g. components/.../lte_mgr.c) not a function
   name

Root Cause (observed)

The CALLS edge has strategy=unique_name, confidence=0.75 and source_id="" (empty).
The source node's qualified_name is the Module node (...lte_mgr.lte_mgr), not a
Function.

The bt (body tokens) property on Function nodes does contain the callee symbol name,
confirming the indexer identified the call — but the edge is not linked to the specific
Function.

Expected Behavior

MATCH (caller:Function)-[:CALLS]->(callee:Function)
WHERE callee.name = 'lp_uart_init'
RETURN caller.name, caller.file_path, caller.start_line
Should return the specific caller function (e.g. lte_mgr_init at lte_mgr.c:414).

Impact

• trace_call_path {"from_function": "X"} returns empty for cross-file calls
• "Find callers / impact analysis" queries (a core use case) silently return wrong granularity

Impact

• trace_call_path {"from_function": "X"} returns empty for cross-file calls
• "Find callers / impact analysis" queries (a core use case) silently return wrong granularity
• Scored as correct=1/2 in our A/B benchmark vs grep (8-question VCM C firmware suite)

Workaround

Two-step: get module name from CALLS edge → grep specific function in that file.
Or: get_code_snippet on candidate functions and check their bt field manually.

Environment

• codebase-memory-mcp v0.7.0
• Project: ESP-IDF C firmware (C99, ~113 files, 428 functions, 343 CALLS edges)
• OS: Linux (Ubuntu 24.04)

[DeusData]

Hey, can you try again with 0.8.0 and see if it still has the issue?

[KerseyFabrications]

Confirmed still present on main. Root cause: the enclosing-function resolvers (func_node_name in helpers.c, resolve_func_name_node in extract_unified.c) only read tree-sitter's name field, but a C function_definition has none (the name is in the declarator chain), so the enclosing scope falls back to the module QN and the CALLS edge is sourced to the Module node. C counterpart to the already-fixed #220 (C++ definitions). Fix descends the declarator chain (mirroring resolve_c_declarator_name in extract_defs.c); after it, outbound trace_path and (:Function)-[:CALLS]->(:Function) return rows and total edges rise. PR + regression test (c_caller_attribution) incoming.

[DeusData]

Related: #554 is the C++ out-of-line-method manifestation of this same bug — "CALLS source falls back to the Module node instead of the enclosing function." PR #463 attributes C/C++ CALLS edges to the enclosing function and targets that path. Cross-linking so the general case (here) and the C++ case (#554) stay connected.