Stale files generated by rules that aren't invoked should be removed

### Description of the bug:

If a genrule creates a file, and is then run, the file will stay there until `bazel clean` is run. This can cause issues with incremental builds that glob files.

For example, with rules_python it's possible to have a `py_test` for which `sys.path` contains a directory with files generated by a genrule. If such a file is "moved" to a different location (by updating the genrule) it would still be able to be imported by python until `bazel clean` is run.

I feel like this contradicts the [documentation](https://bazel.build/docs/user-manual#clean):
> Bazel's incremental rebuilds may not be perfect so clean can be used to recover a consistent state when problems arise.
>
> Bazel's design is such that these problems are fixable and these bugs are a high priority to be fixed. If you ever find an incorrect incremental build, file a bug report, and report bugs in the tools rather than using clean.

### Which category does this issue belong to?

_No response_

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

in a new dir, touch `WORKSPACE` and put this in `BUILD`:
```
genrule(
name="test",
outs=["a.txt"],
cmd="echo 'hello' > $@",
)

cc_library(
name="lib",
data=[":test"],
)
```

1. Run `bazel build //:test`
2. Verify that `find bazel-out/ | grep a.txt` prints something, e.g. `bazel-out//darwin_arm64-fastbuild/bin/a.txt`
3. Modify BUILD to replace `a.txt` with `b.txt`
4. Run `bazel build //:test`
5. Verify that `find bazel-out/ | grep b.txt` prints something, e.g. `bazel-out//darwin_arm64-fastbuild/bin/b.txt`
6. Run `find bazel-out/ | grep a.txt` and see that it's still there, despite the fact that there is no rule which generates it

### Which operating system are you running Bazel on?

ubuntu-22.04/x86_64

### What is the output of `bazel info release`?

release 7.4.1

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

_No response_

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

_No response_

### If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

_No response_

### Have you found anything relevant by searching the web?

_No response_

### Any other information, logs, or outputs that you want to share?

_No response_

Start with the minimal WORKSPACE and BUILD reproduction in the issue, run the listed Bazel builds, and inspect bazel-out before and after renaming a.txt to b.txt. Trace the incremental build and output-cleanup entry points; done means the obsolete a.txt is removed without running bazel clean, with regression coverage for the rename case.

Written by the indexing model from the issue text.