fix(affected): follow a Rust path through a re-exported module

[calvin-archastro]

What

--related now follows a Rust path through a module that another module re-exports.

// app/src/lib.rs
pub use parts::*;            // parts has `pub mod ports`

// app/src/engine.rs
use crate::ports::Runner;    // is parts::ports::Runner
impl Runner for Engine { fn run(&self) -> u32 { 1 } }

Before, crate::ports::Runner stopped at app/src/lib.rs, because ports is not a module of app. Two things followed:

• Runner counted as a trait the workspace does not declare, so run was treated like Display::fmt: a change to it reached every definition that uses the type's file.
• Every file that wrote crate::ports::… counted as a user of the crate root.

Now the path continues into parts::ports, for a glob re-export and for a named one (pub use parts::ports;).

Effect

Measured on a private polyglot monorepo whose main crate re-exports a sibling crate this way:

• For one commit, a changed trait method went from marking 2,601 definitions directly to marking only its callers.
• The overall selection for that commit barely moved (about 657 files with selected tests down to about 600). Other changed definitions in the same commits still reach most of the library through method calls matched by name (get, collect, contains, lock) on values whose type is not written. That is a separate limit and is not addressed here.

Tests

• New: rust_paths_are_followed_through_a_glob_re_export_of_another_crate (fails without the change: an unrelated test in the same crate is selected).
• cargo test: all pass except dev_services::dynamic_port_bundles_are_distinct_propagated_and_released, which fails the same way on main on my machine.
• cargo clippy --all-targets -- -D warnings and cargo fmt --check are clean.

🤖 Generated with Claude Code