Fix crates_repository cache invalidation on Bazel 8

[menny]

Problem

In Bazel 8, --incompatible_no_implicit_watch_label defaults to true (bazelbuild/bazel#23861). This means repository_ctx.path(label) no longer implicitly watches the resolved file for changes.

crates_repository resolves its cargo_lockfile, lockfile, and manifests inputs via repository_ctx.path(label) but never explicitly calls repository_ctx.watch() on them. As a result, when these files change on disk, Bazel doesn't know it needs to re-fetch the repository — the generated defs.bzl becomes stale, causing errors like:

      Error in fail: Tried to get all_crate_deps for package <name> but that package had no Cargo.toml file

This is especially painful in setups where crates_repository inputs come from another external repository (e.g local_repository) with a long-running Bazel server. CI is unaffected because it always starts with clean state. The only workaround today is bazel clean or bazel sync --only=<repo>.

Fix

Add explicit repository_ctx.watch() calls for cargo_lockfile, lockfile (optional, guarded by if lockfiles.bazel), and each entry in manifests, immediately after get_lockfiles() returns in _crates_repository_impl.

Testing

Verified in a large monorepo (Bazel 8.6.0, rules_rust 0.66.0) with a nested workspace where crates_repository inputs come from a local_repository. Before the fix, changing Cargo.toml or lock files required bazel clean to pick up changes. After the fix, Bazel automatically re-fetches the crate repositories.

Related

• crates_repository lockfile hash doesn't match in nested workspaces #2125 — related lockfile hash mismatch in nested workspaces
• --incompatible_no_implicit_watch_label bazel#23861 — the Bazel flag change that caused this

[UebelAndre]

Thanks!