branch-4.1: [fix](ci) migrate macOS BE UT off retired image

[hello-stephen]

Problem

The branch-4.1 macOS BE UT workflow still requests macos-13.

GitHub retired the macos-13 hosted-runner image on December 4, 2025. Jobs now remain queued without a runner assignment. Current examples:

• PR branch-4.1: [fix](eager-agg) null-to-non-null safety check and remove redundant normalize calls in eager aggregation #66208: job 90482850046, queued since 2026-07-29 04:37 UTC
• PR branch-4.1: [fix](test) bound recycler polling waits #66237: job 90582616675, queued since 2026-07-29 12:58 UTC

Both jobs report labels=[macos-13] with an empty runner_name.

Change

Switch the workflow to the supported Intel macos-15-intel label and explicitly select Homebrew LLVM 18. The Intel image preserves compatibility with the branch's x86_64 thirdparty archive and AVX build flags, while LLVM 18 satisfies branch-4.1's Clang 16 minimum and provides a current matching libc++.

Select the prebuilt thirdparty archive from uname -m and resolve JDK 17 through /usr/libexec/java_home -v 17. GitHub currently assigns an arm64 host to this label, so hard-coding the old x86_64 archive and JAVA_HOME_17_X64 is not portable.

Also include .github/workflows/be-ut-mac.yml in the workflow's own path filter. This makes a workflow-only PR run the actual Ccache and BE UT steps, providing target validation for future runner changes.

Use curl -fL for the thirdparty archive and fall back to the common automation release only when a branch-specific asset is unavailable. The automation-4.1 release does not exist, while the common release contains the required x86_64 archive.

Install Homebrew libomp and pass its include/library paths to CMake. AppleClang on the macOS 15 image does not ship the OpenMP runtime; this follows the existing master workflow's compatibility setup.

Split CMake's multi-part OpenMP_CXX_FLAGS before applying them to PCH and global C++ compilation. On AppleClang, FindOpenMP returns -Xclang -fopenmp; treating that string as one argument causes clang to reject it.

Keep the Clang PCH option grouped with CMake's SHELL: syntax. Once OpenMP adds other -Xclang pairs, CMake option de-duplication can otherwise separate -fno-pch-timestamp from its required -Xclang prefix.

Unlink the Homebrew fmt headers after dependency setup. The Intel image exposes its latest fmt under /usr/local/include, which shadows and mixes with the branch-pinned fmt from the Doris thirdparty archive.

The macos-15-intel investigation showed that both its default Xcode 16.4 / AppleClang 17 and its oldest Xcode 16.0 reject branch-4.1's DateV2Value trivial-copy assertions. Homebrew LLVM 16 is also unsuitable because its libc++ rejects the branch's constexpr std::string and dependent static_assert(false) patterns.

Validation

• YAML parse succeeded.
• git diff --check succeeded.
• Head 00aab152 proved macos-15-intel receives a GitHub-hosted Intel runner and completes setup, checkout, and path filtering. Its BE UT step was skipped because the old path filter ignored workflow-only changes.
• Head 5cd92b90 ran the target step on macos-15-intel; job 90722331359 finished with failure because the old workflow downloaded a 9-byte response from the nonexistent automation-4.1 asset and tar rejected it.
• Head ff7fb9e2 proved the asset fallback works and progressed into CMake configuration; job 90724954885 finished with failure at the next shared-image incompatibility, Could NOT find OpenMP_C.
• Head d7dd1944 proved the Homebrew OpenMP setup works and compiled 6860/9581 targets; job 90726643757 then exposed a PCH flag-list bug where clang received -Xclang -fopenmp as one argument.
• Head e481a229 proved the OpenMP flag split works; job 90730432792 reached the PCH target and exposed CMake de-duplication separating -fno-pch-timestamp from -Xclang.
• Head 26d11954 proved the grouped PCH option works and compiled 6959/9581 targets; job 90733847807 then failed because /usr/local/include/fmt from the shared Homebrew image shadowed the branch-pinned thirdparty headers.
• Head 12fd20d3 proved the Homebrew fmt unlink works and compiled 6960/9581 targets; job 90737720669 then exposed that the keg-only LLVM 16 installation was unused and the job instead compiled with /usr/bin/clang++ / AppleClang 17, failing the branch's DateV2Value trivial-copy assertions.
• Head 72e105f191 proved the explicit compiler selection works (Clang 16.0.6, /usr/local/opt/llvm@16/bin/clang++) and reached 6960/9581 targets; job 90743117287 then failed because Homebrew LLVM 16's libc++ rejects branch-4.1's constexpr std::string and dependent static_assert(false) patterns.
• Head 6d70ab2889 proved Xcode 16.0 selection works (AppleClang 16.0.0.16000026) but job 90749132035 still failed at 6960/9623 on the same DateV2Value trivial-copy assertions.
• Head a8829c5967 proved the macos-14 host starts the target step and exposes the requested Xcode installation. Job 90753706832 then showed that the current host is arm64: the hard-coded x86_64 runtime inputs left Java 25 active, and run-be-ut.sh stopped before compilation because JDK 17 is required.
• Head 5983fc4fc2 proved architecture-aware thirdparty selection and JDK 17 resolution work. Job 90754616400 reached CMake configuration with the matching arm64 asset and JDK 17, then correctly rejected AppleClang 15 because branch-4.1 requires Clang 16 or newer.
• Head 49eaf49324 showed that the arm64 macos-14 image does not install Xcode 16.0, so it cannot satisfy branch-4.1's compiler minimum with an Apple toolchain.
• Head 2a484f749e returns to the supported Intel image and selects the current LLVM 18 toolchain, retaining the architecture/JDK, asset, OpenMP, PCH, and fmt fixes above. Its new macOS job must finish the actual BE UT step successfully before this PR is considered validated.

GitHub retirement notice: https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?