feat: add MUSA CICD supports.

[fay85]

Description

After #2179 (USE_MUSA independent of CUDA), this PR makes the MUSA tree link and adds compile-only GitHub Actions CI.

Layers stay on layers/common. This does not add a separate MUSA linear/MLP/attention/Qwen3 stack.

Kernels (xllm/core/kernels/musa)

Stop compiling CUDA sources that do not build under mcc, and replace them with MUSA implementations:

Remove from MUSA CMake	Add
../cuda/block_copy.cu	paged_cache.cu (block_copy)
../cuda/norm.cu	rms_norm / fused_add_rms_norm in gemma_norm.cu
../cuda/moe/moe_fused_topk.cu	moe_fused_topk.cu
../cuda/reshape_paged_cache.cu	(already covered by existing MUSA paged-cache path)

Also add musa_ops_library.cpp so ensure_xllm_ops_registered and kernel::cuda::block_copy (called from worker_impl.cpp) still link on MUSA.

Graph executor

musa_graph_executor_impl reads paged-KV host mirrors from attn_metadata->fa3_metadata instead of the old AttentionHostInput fields.

CI

Same shape as NPU/CUDA: cibuild/build_musa.sh does docker pull then docker run against a public registry image. Build logic and clang/mcc overlays are versioned in-tree under cibuild/musa* (not only inside the image).

• Runner: xllm-cpu-only-cicd
• Image: registry.mthreads.com/presale/devtech/xllm:CICD-build-0813 (compiler, vcpkg, third_party snapshot)
• Checkout without submodules: recursive (gitcode is unreachable from CI). The in-tree script seeds third_party from /opt/xllm-third_party and logs repo gitlinks vs cibuild/musa/third_party_seed.txt.
• Compile-only: cibuild/musa/build.sh (cmake + ninja, no setup.py). No --runtime=mthreads.

This PR touches .github / cibuild, so the MUSA build job waits for review approval (same sensitive-file rule as NPU). Later code-only PRs pull the image automatically.

Related Issues

N/A

Change Type

• Bug fix
• New feature
• Performance improvement
• Refactor
• Documentation
• Test
• Build or CI

Pull Request Checklist

Thank you for contributing to xLLM. Before requesting review, please make sure the following items are complete.

PR Title and Commit Messages

• The PR title and each commit message follow the xLLM commit format: <type>: <subject>.

Allowed types: feat, bugfix, docs, test, refactor, chore, style, revert, perf, model, build, release.
The subject should use clear English, start with a verb, include at least 4 words, and end with ..

Pre-commit Checks

• I have installed pre-commit by running pip install pre-commit or an equivalent command.
• I have installed the hooks with pre-commit install.
• I have run pre-commit run --all-files and fixed any reported issues.

If you are unsure how to set up pre-commit, see the pre-commit documentation.

Self Review

• I have self-reviewed the code according to .agents/skills/code-review/references/custom-code-style.md, especially code written or assisted by AI.
• I have rebased this PR onto the latest main branch.

Build and Test Coverage

• Tests have been added or updated as needed.
• CUDA: python setup.py build test has passed on a CUDA machine.
• NPU: python setup.py build test has passed on an NPU machine.
• MLU: python setup.py build test has passed on an MLU machine.

Reviewer Notes

Please review CMake/kernel wiring and the workflow (no recursive submodules). Clang/mcc workarounds are image-local overlays, not common-header changes.

[yinjiawei01]

Since third_party is sourced from /opt/xllm-third_party in the image instead of the repository submodules, changes to third_party revisions in the PR won't be reflected in MUSA CI. Could we make the bundled third-party revisions traceable to the xLLM revision being tested?

[fay85]

Agreed this was a real gap. The runner cannot submodules: recursive because gitcode is unreachable, so CI still seeds third_party from /opt/xllm-third_party in the image. The seed is now stamped in-tree at cibuild/musa/third_party_seed.txt (xLLM 6f702778 / CICD-build-0813), and cibuild/musa/_build_cuda_graph_musa.sh logs git ls-tree gitlinks next to that stamp so a mismatch is visible in the job log. Bumping submodule revisions still requires rebuilding the image; we cannot fetch those repos from this runner.

[yinjiawei01]

The actual build script comes from /opt/xllm-musa-build/_build_cuda_graph_musa.sh inside the image, so the build logic is no longer tied to the xLLM commit. Could we put the build commands directly in the workflow instead, so that the build logic is versioned together with the xLLM code?

[fay85]

Moved the build logic into the xLLM tree. cibuild/build_musa.sh only pulls/runs the image; cibuild/musa/_build_cuda_graph_musa.sh (cmake + ninja, no setup.py), ninja/link wrappers, and clang/mcc overlays under cibuild/musa-compat/ are invoked from the checkout so they version with the commit. The image stays the compiler / vcpkg / third_party snapshot.