[7.3.1] Lockfile is always considered out-of-date if --incompatible_use_plus_in_repo_names is set

[Wyverald]

Description of the bug:

If --incompatible_use_plus_in_repo_names is set, Bazel 7.3.0 generates a lockfile with version 12. However, this lockfile is always considered out-of-date by Bazel, since it doesn't recognize that 12 is actually the correct version when --incompatible_use_plus_in_repo_names is set, and still expects 11 (see https://cs.opensource.google/bazel/bazel/+/release-7.3.0:src/main/java/com/google/devtools/build/lib/bazel/bzlmod/BazelLockFileFunction.java;drc=691149afd591078dc616e0143bc92bed96deedb3;l=106)

Which category does this issue belong to?

External Dependency

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

echo '7.3.0' > .bazelversion
echo 'common --incompatible_use_plus_in_repo_names' > .bazelrc
touch MODULE.bazel
bazel mod graph
# Now we have a MODULE.bazel.lock file
bazel clean --expunge
bazel mod graph --lockfile_mode=error  # FAILS!

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

7.3.0

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

[Wyverald]

This is kind of a weird one, as it doesn't exist on master, only on release-7.3.0 (well, and release-7.3.1). On master, this flag is enabled by default, and cannot actually be turned off -- so the fix will only apply to the release branch.