fix(rust): resolve module-qualified calls via qualifier-verified cross-file resolution

[okinoxis]

Problem

For Rust, scoped calls (module::function(...)) are dropped at extraction when the callee is not defined in the same file (extractors/rust.py). Since the module-qualified call is the DOMINANT idiomatic intra-crate call form, this makes the call graph blind to most cross-file Rust edges: a real production caller of scan_substrate::accumulate_observations(...) showed 0 dependents while grep found the call site immediately. Every downstream consumer (blast-radius queries, dependents listings) silently under-reports, which pushes users back to grep — defeating graph-first navigation exactly where it matters.

The drop was intentional: resolving scoped calls by BARE last-segment lookup across crate boundaries produced spurious INFERRED edges (#908). The guard is right; the lost signal is not.

Solution

Keep the #908 guard, but stop discarding the qualifier — use it as the verification key:

1. extractors/rust.py — an unresolved scoped call is enqueued into raw_calls with is_scoped_call: True and its scope_qualifier (the path field text of the scoped_identifier), instead of being dropped.
2. extract.py (shared cross-file pass) — a new branch handles is_scoped_call BEFORE bare-name resolution and never falls through to it:
   • The last qualifier segment names the defining module. Rust's compiler-enforced naming convention (modules snake_case, types UpperCamelCase — rustc warns otherwise) cheaply separates module::func() from Type::method() / Enum::Variant; uppercase qualifiers keep their existing behavior (skipped).
   • crate / super / self qualifiers require real module-tree resolution and are conservatively skipped.
   • A candidate survives only if its defining file IS the named module (<seg>.rs or <seg>/mod.rs); require exactly one survivor or bail (god-node guard preserved).
   • Emitted as EXTRACTED (confidence 1.0): the module is named explicitly in source — the same reasoning as the existing qualified-class-method passes (Python qualified class-method calls miss EXTRACTED edges #1446/Swift: static method calls (MemberAccessExpr) don't create caller→type edges + overloaded methods collapsed into single node #1533).
3. symbol_resolution.py — the same qualifier-verified branch in resolve_cross_file_raw_calls, so scoped entries can never reach that path's bare-name resolution either (defense in depth; pair-dedup makes double emission impossible).

Results (real-world Rust crate, ~200 source files, 14k-edge graph)

• The motivating case resolves: scan_substrate::accumulate_observations → its caller, EXTRACTED at the exact source line.
• Graph-wide: +138 EXTRACTED edges (qualifier-verified), −388 INFERRED edges (risky bare-name resolutions either promoted with verification or dropped — the #908 class shrinking), net +159 edges all with provenance.
• No regressions on control symbols (bare-name-called functions keep their dependents).

Suggested tests

1. Two modules a.rs/b.rs, b::helper() called from a → one EXTRACTED edge to b.rs's helper, none to a same-named helper in c.rs.
2. mod.rs form: call util::helper() with util/mod.rs defining helper → resolves.
3. Ambiguity guard: helper defined in BOTH b.rs and b/mod.rs (pathological) → no edge (two survivors).
4. Type::method() / Enum::Variant (uppercase qualifier) → unchanged behavior (no new edge).
5. crate::x::helper() / super::helper() / self::helper() → skipped (no spurious edge).
6. Turbofish m::<T>-adjacent shapes → qualifier normalization strips generics.

Known limitations (documented, out of scope here)

• crate::/super::-qualified paths still unresolved (needs module-tree walking).
• use alias resolution (use a::b as c; c::f()) not attempted.
• bin→lib fully-qualified paths still unresolved (crate-name qualifier ≠ file stem).

[safishamsi]

Thanks @okinoxis — the problem is real and the qualifier-verified direction is right (the ambiguity bail-out and the untouched unqualified-call path are both good). Before this can land, two false positives need fixing, because as written it emits wrong edges at EXTRACTED (highest) confidence:

1. External std calls bind to a local same-named module. std::fs::read("x") with an unrelated local fs.rs that defines read produces an edge to the local read. The std:: prefix is dropped and only the last segment is matched against the file basename. Shadowing std module names (fs, io, mem, time) with local wrapper modules is common Rust, and read/write/get are exactly the generic names the trait-method blocklist already exists to keep out.

2. Cross-language phantom edges. A Rust b::helper() binds to a Python b.py that defines helper, because the new branch runs before the existing cross-language guard and matches on stem across all languages.

Suggested changes:

• Restrict candidates to Rust sources (.rs / rust language family).
• Verify the full qualifier suffix right-to-left against parent directory names, not just the last segment against the basename; stop at crate/super/self. Then std::fs::read vs src/fs.rs fails on std vs src, while crate::util::helper vs src/util.rs still resolves.
• For single-segment use std::fs; fs::read() with a local fs.rs, use the file's use roots (already parsed) to skip when the qualifier is imported from a non-crate/self/super path.
• Please add tests — the PR body suggests them but none are included — including the two negatives above.
• Needs a rebase; it currently conflicts with v8.

Happy to re-review once these are in.