feat(cambricon): link Apex rms_norm

[voltjia]

Summary

• Add Cambricon Apex rms_norm_affine as linked rms_norm implementation slot 16.
• Resolve a second Apex DSO, fused_layer_norm_cuda*.so, without changing the existing glu_activation*.so mapping.
• Map Apex empty-bias, axis, and vector<Tensor> return semantics inside the provider adapter.

Motivation

This PR validates that the linked architecture works across operators and across materially different provider ABIs. InfiniOps keeps:

rms_norm(input, weight, epsilon, out)

Cambricon Apex exports:

std::vector<at::Tensor> rms_norm_affine(
const at::Tensor& input, const at::Tensor& bias,
const at::Tensor& weight, double epsilon, long axis);

nm -D -C, readelf, DWARF, and direct small-tensor calls confirmed this ABI. The adapter supplies an empty FP32 CPU bias, uses axis = input.dim() - 1, and copies result element 0 to out; element 1 is auxiliary inverse RMS.

Depends on #885. N/A - no linked issue.

Type of Change

• feat - new feature / new operator / new platform
• fix - bug fix
• perf - performance improvement (no behavioral change)
• refactor - code restructuring without behavior change
• test - adding or fixing tests only
• docs - documentation only
• build / ci - build system or CI configuration
• chore - tooling, formatting, or other non-code changes
• Breaking change

Platforms Affected

• CPU (WITH_CPU)
• NVIDIA (WITH_NVIDIA)
• Iluvatar (WITH_ILUVATAR)
• MetaX (WITH_METAX)
• Cambricon (WITH_CAMBRICON)
• Moore (WITH_MOORE)
• Ascend (WITH_ASCEND)
• PyTorch C++ bindings (WITH_TORCH)
• Build system / CMake / CI
• Python bindings / user-facing API

Smoke Test Result

Pending: operator-pruned Cambricon linked build, tests/test_rms_norm.py, and the existing smoke set.
The source upload to the Cambricon validation host requires explicit authorization.

Test Results on Supported Platforms

Platform	Affected	Build / Smoke Result	Full Result / Notes
NVIDIA	No	N/A - not affected	Host-independent clang-format/Ruff checks only
Iluvatar	No	N/A - not affected	N/A
MetaX	No	N/A - not affected	Separate draft PR
Cambricon	Yes	Pending remote linked build	Six direct provider calls passed for FP32/FP16/BF16 and 2D/3D inputs
Moore	No	N/A - not affected	Separate draft PR
Ascend	No	N/A - not affected	N/A

Static validation and provider evidence

DSO: fused_layer_norm_cuda.cpython-310-aarch64-linux-gnu.so
SHA256: 04efea65896ff222f2cbc85f27eccadcab83ae56ff9132223b086e86428682fd
required symbol:
rms_norm_affine(at::Tensor const&, at::Tensor const&, at::Tensor const&, double, long)
clang-format 21 --dry-run --Werror <changed C++ files>
exit 0
ruff 0.15.22 format --check tests/test_rms_norm.py
1 file already formatted
ruff 0.15.22 check tests/test_rms_norm.py
All checks passed!
git diff --cached --check
exit 0

Benchmark / Performance Impact

N/A - this PR validates linked integration correctness and makes no performance claim.

Notes for Reviewers

• The shared TorchRmsNorm<Backend> remains provider-neutral; only ApexRmsNorm::Call knows about bias synthesis, axis, and the auxiliary return.
• This proves that one Python distribution may resolve multiple linked DSOs without combining their mappings.
• This is the seventh PR in the linked-operator stack and depends on feat(moore): link vLLM rms_norm #885; its diff contains only the Cambricon provider, second Apex DSO mapping, and MLU stream coverage.