[Bug]: //tools:add_module prompts for compatibility level without explaining what that is

[pjh]

What happened?

This is a tool bug and/or a doc bug.

https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md#contribute-a-bazel-module says to run the interactive helper script to contribute a new module. When I run the script it asks me for a "compatibility level", but the tool nor that doc page explain what a compatibility level is.

$ bazel run //tools:add_module
Starting local Bazel server and connecting to it...
INFO: Analyzed target //tools:add_module (86 packages loaded, 3095 targets configured).
INFO: Found 1 target...
Target //tools:add_module up-to-date:
  bazel-bin/tools/add_module
INFO: Elapsed time: 19.415s, Critical Path: 0.57s
INFO: 5 processes: 5 internal.
INFO: Build completed successfully, 5 total actions
INFO: Running command line: bazel-bin/tools/add_module
INFO: Getting module information from user input...
ACTION: Please enter the module name: nsync
ACTION: Please enter the module version: 1.27.0
ACTION: Please enter the compatibility level [default is 0]: 

Version

Output of bazel --version: bazel-7.0.2

Version of relevant rules from the WORKSPACE or MODULE.bazel file: I cloned this repository at 4f09b04

How to reproduce

bazel run //tools:add_module

Any other information?

No response

[pjh]

A later step in the tool includes a helpful link: ACTION: Do you want to specify an existing presubmit.yml file? (See https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#presubmit) [y/N]:. Perhaps a helpful link could be added for the compatibility level prompt also.

[fzakaria]

https://bazel.build/rules/lib/globals/module#module

default is 0
The compatibility level of the module; this should be changed every time a major incompatible change is introduced. This is essentially the "major version" of the module in terms of SemVer, except that it's not embedded in the version string itself, but exists as a separate field. Modules with different compatibility levels participate in version resolution as if they're modules with different names, but the final dependency graph cannot contain multiple modules with the same name but different compatibility levels (unless multiple_version_override is in effect). See [the documentation](https://bazel.build/external/module#compatibility_level) for more details.

I thin the default should be 1 now.