cargo: Fix duplicate Cargo.lock entries for feature-gated git dependencies

[jurre]

Summary

Fixes invalid Cargo.lock files produced when a project has an optional SSH git dependency behind a non-default feature.

Problem

When Dependabot updates a dependency (e.g., regex) in a Cargo project that has a feature-gated optional SSH git dependency, the lockfile updater produces two [[package]] entries with the same (name, version, source) triple but different dependency lists. Cargo rejects this at parse time:

error: failed to parse lock file at: .../Cargo.lock
Caused by: package `ghapi-rs` is specified twice in the lockfile

Root cause

prepared_manifest_content swaps SSH→HTTPS URLs in manifests so cargo can fetch through the proxy without SSH keys. But the lockfile was written with the original SSH URLs. Cargo sees the HTTPS URL in the manifest and the SSH URL in the lockfile as different sources, so it re-resolves the git dependency via HTTPS with only default features — creating a second [[package]] entry with fewer dependencies. post_process_lockfile then swaps HTTPS→SSH in the output, making both entries share the same identity but with different dep lists.

Fix

Apply the same SSH→HTTPS swap to the lockfile before writing it to disk, so cargo sees consistent URLs in both manifest and lockfile. Cargo then recognizes the existing lockfile entry, doesn't re-resolve the git dep, and produces no duplicates. post_process_lockfile already handles swapping URLs back to SSH afterward.

The production change is a single line:

- File.write(lockfile.name, lockfile.content)
+ File.write(lockfile.name, replace_ssh_urls(T.must(lockfile.content)))

Verification

• CLI reproduction: Created two public repos (jurre/repro-crate, jurre/helper-crate) mirroring the customer's structure. Verified dependabot update via CLI produces duplicate entries before the fix and a single correct entry after.
• Unit tests: Two new tests verifying the lockfile is written with HTTPS URLs and the final output has SSH restored with no duplicates.
• Full test suite: 33/33 lockfile updater specs pass, rubocop clean.

[Copilot]

Pull request overview

This PR aims to prevent Cargo from producing invalid Cargo.lock output when updating a project that includes SSH-based git dependencies behind non-default features, by ensuring Cargo sees consistent git source URLs during the update.

Changes:

• Write the temporary Cargo.lock with SSH git URLs rewritten to HTTPS before running cargo update.
• Add a new lockfile updater spec context for an SSH URL + feature-gated git dependency scenario.
• Add new manifest/lockfile fixtures for the above spec.

Show a summary per file

File	Description
cargo/lib/dependabot/cargo/file_updater/lockfile_updater.rb	Writes the temporary lockfile with SSH→HTTPS URL rewriting to avoid source mismatches during cargo update.
cargo/spec/dependabot/cargo/file_updater/lockfile_updater_spec.rb	Adds a regression spec around feature-gated SSH git dependencies and URL swapping behavior.
cargo/spec/fixtures/manifests/feature_gated_git_dep_ssh	New Cargo.toml fixture modeling a feature-gated optional SSH git dependency.
cargo/spec/fixtures/lockfiles/feature_gated_git_dep_ssh	New Cargo.lock fixture used by the regression spec.

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 2

[Copilot]

This new spec context doesn’t actually reproduce the reported failure mode (two [[package]] stanzas with the same (name, version, source) but different dependency lists). The stubbed run_cargo_command only updates the time stanza, so the spec won’t fail if the duplicate-entry bug reappears. Consider adjusting the stubbed Cargo.lock output to include both the SSH- and HTTPS-sourced entries (with different dependency lists) and assert the final lockfile contains only the correct single entry.

[jurre]

Addressed: the test stub now conditionally injects the duplicate entry based on whether the lockfile still has SSH URLs — simulating cargo's actual behavior. If the fix is reverted, the stub produces the duplicate and both tests fail (verified).