fix(core): scope Rust impl methods to their type, dedup class-scoping walk

[pradeepmouli]

Summary

tree-sitter-rust's impl_item node has no name field — only body, trait, type, and type_parameters (verified against the crate's real node-types.json, not assumed). find_parent_class's generic child_by_field_name("name") walk silently returns None for it, so every Rust impl method — inherent or trait — fell back to a flat, unscoped file::method id instead of file::Type::method.

Concretely, this meant any two types in the same file with a same-named method (e.g. both implementing Display, or both having a new()) silently collapsed into a single graph symbol, with the second one dropped entirely by store_parquet.rs's sym_seen dedup guard — not just mis-scoped, actually missing from the graph.

Reproduced empirically before fixing: indexing a fixture with struct Alpha (impl Alpha { fn hello(&self) -> String }) and struct Beta (impl Greet for Beta { fn hello(&self) -> String }, identical signature) produced only one hello symbol in the graph — Beta::hello was silently absent.

Fix

• rust/entities.scm's impl-method pattern now also captures the impl's own type: field as @method.parent (the Self type, e.g. Bar in impl Foo for Bar).
• entities.rs consumes @method.parent through the same decompose-query mechanism (inherit_decompose_query) that relation extraction already uses for compound INHERITS-edge bases (generic/qualified impl targets) — reused, not duplicated. Falls back to the existing ancestor walk when the capture is absent, following the same capture-with-fallback idiom already established for @func.params/@func.return_type.
• Along the way, consolidated find_parent_class (entities.rs) and find_enclosing_class (relations.rs), which had drifted into two independently-buggy copies of the same class-scoping walk (one had struct_specifier and the C++ out-of-line-method branch, the other had Elixir's defmodule and Pascal's declClass/declIntf) — now one shared function in extract/mod.rs, used by both.

No schema change; purely additive to entities.scm/entities.rs. Does not touch relations.scm.

Known residual gap (not fixed by this PR)

A single type with two same-named methods from different sources — e.g. an inherent impl and a trait impl of the same type (impl Bar { fn x() {} } + impl SomeTrait for Bar { fn x() {} }) — still collide, since both resolve @method.parent to the same type name. That's a genuine overload-disambiguation problem, not a scoping bug, and needs separate work (tracked in my fork, not part of this PR's scope). The added test test_rust_same_type_inherent_and_trait_impl_method_still_collide documents this explicitly as a known, tracked gap rather than letting it pass silently as "fixed."

Testing

• Two new regression tests in entities.rs's test module: one confirms the fix (Alpha::hello/Beta::hello now survive as distinct, correctly-scoped symbols), one explicitly documents the known residual gap above.
• Added tree-sitter-rust as an infigraph-core dev-dependency to hand-build the test's Query directly (mirroring the existing Kotlin/Dart test pattern) — using infigraph_languages::bundled_registry() from inside infigraph-core's own inline tests hits a dev-dependency-cycle type mismatch (two distinct compiled instances of ParserBackend), confirmed via compiler error, not guessed around.
• Verified independently on a fresh worktree off upstream/main (not reusing my fork's branch results): cargo build --release -p infigraph-cli -p infigraph-mcp succeeds, full workspace cargo test --workspace --lib passes (738 tests, 0 failures), cargo fmt --all -- --check clean.
• Note on clippy: cargo clippy --all-targets -- -D warnings on bare upstream/main (before this PR's changes) currently fails on an unrelated pre-existing lint in crates/infigraph-core/src/embed/mod.rs (chunks_exact_to_as_chunks) — confirmed this file isn't touched by this PR's diff at all, so it's local-toolchain-vs-CI drift (per this repo's own CLAUDE.md: dtolnay/rust-toolchain@stable floats, so a newer local clippy can surface lints CI's pinned version doesn't), not something this PR introduces or is responsible for fixing.

🤖 Generated with Claude Code