Cargo workspace-inherited renames lose internal dependency edges

[oleksii-tumanov]

What happened?

graphify extract --cargo loses an internal dependency when a member inherits
a renamed dependency from [workspace.dependencies]. Both crate nodes appear,
but the dependency edge is missing. The same rename works when declared directly
in the member's [dependencies].

Steps to reproduce

Create this workspace:

# Cargo.toml
[workspace]
members = ["app", "storage"]
resolver = "2"

[workspace.dependencies]
db = { path = "storage", package = "internal-storage" }

# app/Cargo.toml
[package]
name = "app"
version = "0.1.0"
edition = "2021"

[dependencies]
db.workspace = true

# storage/Cargo.toml
[package]
name = "internal-storage"
version = "0.1.0"
edition = "2021"

Add an empty src/lib.rs in each member. From the workspace root, run:

cargo metadata --format-version 1 --no-deps --offline
python -c 'from graphify.cargo_introspect import introspect_cargo; print(introspect_cargo("."))'

Cargo identifies the app dependency as package internal-storage, renamed to
db. The direct introspection call used by --cargo bypasses the AST cache.

Error output or graph output

Graphify emits nodes crate:app and crate:internal-storage, but edges is [].
Expected: a crate_depends_on edge from crate:app to crate:internal-storage.

Graphify version

0.9.65, reproduced on v8 at 20a20d30d8e7eef77675651f0199d87f913bd3e7.

Environment

macOS, Python 3.12, installed from the frozen uv lockfile with all extras.

Additional context

The member entry contains only workspace = true; its package and path
come from the root declaration. Direct dependency renames were fixed in #1861.
This report concerns inherited dependency identity, not nested manifest discovery
or additional dependency kinds. A registry-only inherited alias must also stay
external even when a workspace member happens to have the same name.

[safishamsi]

Fixed in v0.9.66 via #3734 — workspace-inherited dependency identity resolves. Thanks @oleksii-tumanov.