local_repository() pointing into workspace is not invalidated when external repo file checking is disabled.

### Description of the bug:

Hi!

I noticed that our warm Bazel implementation started complaining about inconsistent file sizes in `@@+local_repository+blah//`, when someone edited `//third_party/blah/BUILD`. It turns out that this repo was configured as

```
local_repository(
name = "blah",
path = "third_party/blah",
)
```

We are running with `--watchfs --experimental_check_external_repository_files=false`.

I am 99% sure that this problem is caused by `--noexperimental_check_output_files` not specially treating external repositories that point back into the source tree.

My gut feeling is that making this work will be hard, and I wonder if we could instead forbid this?

### 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.

_No response_

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

_No response_

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

_No response_

### 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` ?

```text

```

### 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 by reproducing the interaction between local_repository(path = "third_party/blah"), --watchfs, and --experimental_check_external_repository_files=false after editing the external repository's BUILD file. Trace the invalidation behavior for workspace-backed external repositories and determine whether the intended result is correct invalidation or rejecting this configuration; done means the inconsistency is eliminated and regression coverage exists.

Written by the indexing model from the issue text.