Incorrect Bazel aliases generated for patched crates using crates_vendor

[jayzhuang]

Description

When using crate_universe with patched crates (e.g., using [patch.crates-io] to point to a local fork), the generated Bazel aliases in the vendor BUILD.bazel file incorrectly point to the default vendored location instead of the patched local path.

This causes Bazel builds to fail because it cannot find the crate at the expected vendored location, since the vendored one doesn't exist. Note the rust_library build target is correctly generated at the patched location.

High-level reproduction steps

1. Set up a Rust project using crate_universe and use crates_vendor.
2. Add a dependency on a crate (e.g., rand).
3. Patch that crate to a local path in Cargo.toml:

   [patch.crates-io]
   rand = { path = "fork/rand" }

4. Run crate_universe to generate Bazel files.
5. Inspect the aliases in the generated BUILD.bazel in the vendor directory.

Expected behavior

The alias for the patched crate should point to the local path:

alias(
    name = "rand",
    actual = "//fork/rand:rand",
    tags = ["manual"],
)

Actual behavior

The alias points to the vendored location (which might not even exist or contains the incorrect version):

alias(
    name = "rand",
    actual = "//vendor/rand-0.8.5:rand",
    tags = ["manual"],
)

Possible root cause

The issue could lie in crate_universe/src/rendering.rs, specifically in the crate_label function. This function constructs Bazel labels using a fixed template based on the crate name and version, without considering if the crate has a local path override (e.g., from a patch).

fn crate_label(&self, name: &str, version: &str, target: &str) -> Label {
    Label::from_str(&sanitize_repository_name(&render_crate_bazel_label(
        &self.config.crate_label_template,
        &self.config.repository_name,
        name,
        version,
        target,
    )))
    .unwrap()
}

Call sites of crate_label (such as make_deps, make_aliases, and render_module_build_file) need to pass the local path information if available, and crate_label should use it to construct the label.