crates_repository lockfile hash doesn't match in nested workspaces

We have a bazel setup that uses two workspaces, one at the root of our repository and one under `nested/`. The majority of our code runs under `nested`, including our `rules_rust` configuration, but we need to run things like `@nested//rust_crate:foo` from both the nested and outer workspaces.

When using `crates_repository` with a `lockfile` argument, we observe that the top-level checksum field of the lockfile generated by `CARGO_BAZEL_REPIN=1 bazel sync` is different depending on which workspace we synced from, even though all other contents of the generated lock file are identical. Because the lockfile is checked on every build of a target, this means that whichever workspace didn't generate it will receive an error about needing `CARGO_BAZEL_REPIN` to be set, making it effectively impossible to use.

The obvious workaround for this is to remove the `lockfile` argument, but it does add some additional overhead for everyone using this since they'll need to do the splicing step.

See attached for a small repro ([rules_rust_2125.tar.gz](https://github.com/bazelbuild/rules_rust/files/12423854/rules_rust_2125.tar.gz)). After extracting the repro, differences can be observed in the generated lockfiles from the following sequence of commands:
```
cd rules_rust_nested
CARGO_BAZEL_REPIN=1 bazel sync --only=crate_index
head nested/Cargo.Bazel.lock
cd nested
CARGO_BAZEL_REPIN=1 bazel sync --only=crate_index
head Cargo.Bazel.lock
```

Let me know if any other details would be helpful here.

Additional info:
OSes tested on: Mac OS 13.4, Ubuntu 20.04
rules_rust versions: 0.26.0 - 0.30.0