Python: aliased from-import across a non-repo-root source root loses the CALLS edge

[dergachoff]

Problem

When the Python source root is not the repo root (setuptools src/ layout, monorepo service dirs), an aliased from-import produces no CALLS edge: trace_path(direction="inbound") returns callers_total: 0 for a function with real callers. The same files with a plain import resolve fine. Found live on v0.9.1-rc.1: two agent sessions concluded a production function had zero callers.

Evidence

Each case freshly indexed on v0.9.1-rc.1:

structure	import	inbound trace
flat, same dir	aliased	caller found
repo-root package (services/)	aliased	caller found
source root under api/ (import says services.callee, QN says api.services.callee)	plain	caller found
same layout, same files	aliased	0 callers

Minimal repro, two files under <repo>/api/services/:

# callee.py
def target_fn(x):
    return x + 1

# caller.py
from services.callee import target_fn as _target_fn

def wrapper(x):
    return _target_fn(x)

index_repository then trace_path(function_name="target_fn", direction="inbound") → callers_total: 0; the plain-import twin repo indexes one more edge (35 vs 34) and finds wrapper. search_graph still shows in-degree 1 (the import edge), so CALLS resolution specifically is the gap.

A plain call resolves by call-site name == target name; the alias forces import-path resolution, which assumes the repo root — services.callee never maps onto api.services.callee. Distinct from #875 (aliased import with repo-root paths, fixed by #979) and #1237 (plain bare import; plain passes here).

Expected fix

Make import-path resolution tolerate non-repo-root source roots (e.g. suffix-match the import path against registered module QNs), with the aliased src-layout case as a regression test.

[vinitgirdhar]

Hello, I can fix this issue. Can you please assign this issue to me?

[DeusData]

Thank you for volunteering to help. PR #1371 is already the active implementation for this issue, so I do not want to assign overlapping work to a second contributor and have both of you spend time on the same fix. I will leave the issue unassigned while that PR is active.

The most useful help would be an independent test of #1371 on a small public Python fixture once the remaining IMPORTS graph-shape decision is resolved. That would add evidence without duplicating the implementation. Thank you for offering.