[helly25]

Make the release build use mbo's pinned Clang toolchain and make the Bazel registry checks use supported compilers. Correct the generated module setup instructions before publishing 0.16.0.

AG;DR

• Add --config=clang to the reusable release workflow's build/test command. Its runner is separate from coverage and does not inherit coverage's compiler selection; relying on Ubuntu's default compiler can select an unsupported baseline.
• Split BCR native-toolchain presubmits into Linux and macOS tasks, retaining both Bazel 9.2.0 and 9.x and the same shared target list. Ubuntu 24.04 installs/selects Clang and libc++ 23 from the official LLVM APT repository using a scoped signed-by key. Configure Bazel's native toolchain to use libc++ for header discovery, compilation, and linking instead of silently retaining Ubuntu's unsupported libstdc++. Apple Clang retains both macOS deployment flags at 11.0; both platforms receive target and host C++23 flags. BCR uses Clang on both platforms; GCC remains covered by main CI and independent archive consumers.
• Audit the source template: the uploaded numeric-tag mbo-<tag>.tar.gz and its mbo-<version>/ prefix already match, so leave it unchanged; the publisher computes archive integrity. Add maintainer github_user_id: 6420169 to the metadata template, matching the published registry entry and GitHub's public user record. Current BCR metadata validation rejects the missing ID.
• Correct generated setup notes to use MODULE.bazel, tag-pin module links, and explicitly register the copied LLVM toolchain (or select it only in a named configuration). Document consumer-owned C++23/deployment flags. Stop recommending copying the checkout-only development module, which now refers to repository-local xxHash fixtures.
• Add configuration regression tests and execute the real release packager in an isolated miniature Git repository. Verify compiler selection, the template's URL/prefix and maintainer identity, patched consumer MODULE.bazel, VERSION.txt, external formatter selection, and rendered setup instructions. Run these checks through focused pre-commit and the existing complete infrastructure-test CI gate.
• Update the infrastructure guide, 0.16.0 changelog, and existing registry/macOS deployment regression.

Validation: bazel test //... (210 passed, one configured skip); exact corrected release command bazel test --config=clang //... --test_tag_filters=-lfs on the final pushed head (209 passed, one configured skip); all 310 infrastructure tests and all applicable focused pre-commit hooks passed. Real archive packaging/validation passed. All ten BCR targets built as independent archive dependencies on macOS. The exact Ubuntu BCR image also built all ten targets and ran the independent consumer using the actual presubmit setup commands and environment (Clang 23.1.6/libc++ 230106), without changes to the pushed tree. The full PR matrix must pass before merging; exact merged-main CI must pass before tagging.

Local verification note: an initial x86 compiler process crashed under ARM-host emulation, and the native comparison encountered a full Docker VM disk. After targeted cleanup of only task-created diagnostic resources, the unchanged x86 build and consumer completed successfully. No checks, compiler diagnostics, signature verification, or repository policies were weakened to obtain that result.

Portability/limitations: no compiler, warning, sanitizer, coverage, or release-readiness gate is weakened. BCR Linux setup requires the official LLVM APT repository (https://apt.llvm.org/); BCR may require a maintainer's presubmit-auto-run label for changed setup commands. Registry publication remains a normal post-release draft PR, not a bypass of upstream review. No release tag or assets have been published by this change.

Follow-up (not part of this release): add a dedicated BCR test module whose root declares the hermetic LLVM toolchain and its own clang configuration. BCR's current anonymous root does not inherit mbo's .bazelrc or development LLVM module, so passing --config=clang alone is not valid there. The explicit Clang/libc++ setup above is retained for 0.16.0.