Advisory false negative: crates with renamed lib targets silently dropped from graph

## Summary `cargo deny 0.19.0` silently drops crates from its dependency graph when the crate has a `[lib] name` that differs from the package name. This causes advisory false negatives — `cargo audit` detects the vulnerability but `cargo deny` does not. ## Root Cause The bug is in `krates` 0.20.0. In `builder.rs` (lines ~1086-1089), when processing features like `dep:rustls-webpki`, the code matches against the resolved dependency name only. When a crate has `[lib] name = "webpki"` in its Cargo.toml, cargo metadata uses the lib name as the resolved dependency name. The match of `"rustls-webpki"` against `"webpki"` fails, and the entire subtree is silently dropped. Notably, a separate function `get_dep_id` (lines ~906-914) correctly handles this case by also checking `dep_name == ndep.pkg.name()`, but the feature traversal code does not have this fallback. ## Impact In our case, `rustls-webpki@0.102.8` (which has `[lib] name = "webpki"`) and all its unique transitive deps (including `ring`) were completely invisible to cargo-deny. This caused RUSTSEC-2026-0049 to go undetected. Our `cargo metadata` resolve shows 680 packages while `cargo deny list` only shows 591 — 89 packages silently missing from the graph. This is a soundness issue for a security auditing tool. Any crate with a renamed lib target and a known advisory will be silently ignored. ## Reproduction 1. Have a dependency that pulls in `rustls-webpki@0.102.8` via a feature like `dep:rustls-webpki` 2. Run `cargo audit` — detects RUSTSEC-2026-0049 3. Run `cargo deny check advisories` — reports no issues 4. Run `cargo deny list` — `rustls-webpki@0.102.8` is absent entirely ## Fix This was fixed in `krates` 0.21.0 (commit `7f461bb`, "Fix lib rename (#107)", 2026-04-01) which adds a `Renames` struct that checks both the resolved name and the package name. Bumping the `krates` dependency in cargo-deny should resolve this.