Label shorthand not treated as "explicit" for incompatibility check

### Description of the bug:

If `//foo/bar:bar` is incompatible, building it as `foo/bar` (no initial `//` and no explicit target name) behaves incorrectly in that it does not seem to count as “explicit” for the purposes of `--noskip_incompatible_explicit_targets`.

### Which category does this issue belong to?

Configurability

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

Create a target `//foo/bar:bar` with `target_compatible_with = ["@platforms//:incompatible"]` and observe the difference in behavior when building as `//foo/bar:bar`, `//foo/bar`, `foo/bar:bar`, and `foo/bar`.

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

Mac

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

release 8.2.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` ?

```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_

Reproduce the behavior on Bazel 8.2.1 using the four target spellings described in the issue, with an incompatible target and --noskip_incompatible_explicit_targets. Then trace how shorthand labels are classified for the incompatibility check; done means shorthand and explicit target forms behave consistently.

Written by the indexing model from the issue text.