Cargo vendor directory collision when same crate version comes from different sources

[taylormadore]

When a single Hermeto request includes two Cargo projects that depend on the same crate at the same version but from different sources (e.g., crates.io registry vs. a git repo), the build always fails for the registry-sourced project with:

error: checksum for <crate> could not be calculated, but a checksum is listed in the existing lock file

Hermeto vendors all Cargo packages into a shared deps/cargo directory using sequential cargo vendor --no-delete --versioned-dirs invocations. Directory names are keyed by name+version only and most importantly not by source. When two projects need the same crate version from different sources, they map to the same directory.

It appears that due to Cargo's internal skip logic, the git source always wins regardless of vendor order. Git sources unconditionally overwrite existing content, while registry sources skip re-vendoring if a .cargo-checksum.json already exists. The git-sourced checksum file has "package": null (git dependencies don't support checksums), which causes a mismatch when the registry-consumer project's Cargo.lock expects a checksum.