--flag_alias fails with LabelSyntaxException when aliasing negated Starlark flags (no@ / no//)

Description of the bug:

In Bazel 9, configuring --flag_alias with a negated Starlark flag (e.g. build --flag_alias=nobool=no@bazel_skylib//lib:bool or no//pkg:flag) passes the initial prefix check in FlagAliasConverter, but fails option parsing / analysis with an unhandled LabelSyntaxException: invalid package name 'no@...': package names may not contain '//' path separators.

Which category does this issue belong to?

CLI, Configurability, Core

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

• pkg/BUILD.bazel

load("@bazel_skylib//rules:common_settings.bzl", "bool_flag")

bool_flag(
    name = "my_feature",
    build_setting_default = True,
)

• .bazelrc

build --flag_alias=nomy_feature=no@demo//pkg:my_feature

• MODULE.bazel

module(name = "demo")
bazel_dep(name = "bazel_skylib", version = "1.8.2")

CLI:

$ export USE_BAZEL_VERSION=9.2.0
$ gbazelisk build //pkg:my_feature --nobuild

Which operating system are you running Bazel on?

x86_64 GNU/Linux

What is the output of bazel info release?

release 9.2.0

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

N/A

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

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

Ran bazelisk bisect

$ bazelisk --bisect=9.0.0..9.2.0 build //pkg:my_feature --nobuild
...
--- Bisect Result

first bad commit is https://github.com/bazelbuild/bazel/commit/897af1683dd5fe69c0be60975f6a96c5a0e4b8dc

Have you found anything relevant by searching the web?

From LLM:

Root Cause in Bazel codebase: In CoreOptionConverters.java:

1. FlagAliasConverter validates the RHS of --flag_alias using STARLARK_SKIPPED_PREFIXES (["--//", "--no//", "--@", "--no@"]), which explicitly allows --no@ and --no//.
2. It then calls convertOptionsLabel(longForm, conversionContext), which expects a standard Label string.
3. Because no@... does not start with @ or /, convertOptionsLabel prepends //, producing //no@demo//pkg:my_feature.
4. Label.parseWithRepoContext() attempts to parse no@demo//pkg:my_feature as a package name, throwing LabelSyntaxException: package names may not contain '//' path separators.

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

Observed error:

ERROR: While parsing option --flag_alias=nobool=no@bazel_skylib//lib:bool: invalid package name 'no@bazel_skylib//lib': package names may not contain '//' path separators