Fix crates_repository cache invalidation on Bazel 8 (#3967)

## 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
- bazelbuild/rules_rust#2125 — related lockfile hash mismatch in nested
workspaces
- https://github.com/bazelbuild/bazel/issues/23861 — the Bazel flag
change that caused this