Feat: 新增面向arch22的aclblasCaxpy任意incx/incy支持及动态共享跨度流水线优化

描述

背景：功能补充

CAXPY 在 2026-07 之前的实现（67fe860 之前）只支持 incx=1, incy=1 的稠密场景：CalTilingData 直接把 n 按核数均分，kernel 只有一条连续读写路径，不识别任意步长。本次改动是在此基础上做的功能补充——让 aclblasCaxpy 按 BLAS 标准语义支持任意（含负数）incx/incy，同时把由此产生的多种步长组合按访问模式分类，分别派发到代价不同的 kernel 实现，而不是所有非 1 的步长都走同一条最慢的兜底路径。

分类讨论：为什么要按 stride 组合分类派发

incx/incy 一旦允许任意值，笛卡尔积上的组合很多，但从"访存模式代价"这个维度看可以收敛成几类（见 CaxpyStrideClass）：

• DENSE（incx=1, incy=1）：退化到原始稠密实现，x/y 都连续，直接搬运最快，没有理由为了统一接口牺牲这条路径。
• X_ONLY_POSITIVE / Y_ONLY_POSITIVE（一侧步长为 1，另一侧为正数）：一侧仍是连续读写，只有另一侧需要 strided gather/scatter，是"部分退化"场景。
• DUAL_SYMMETRIC_POSITIVE（incx==incy，且都为正）：两侧步长相同，gather 和 scatter 用的 offset 表可以共用一份，省一次 offset 表生成。
• DUAL_ASYMMETRIC_POSITIVE（都为正但不相等）：两侧都要 strided 访问，且各自的 offset 表不同，是最一般的正步长情况。
• NEGATIVE_MIXED（只要有一侧为负）：BLAS 标准里负步长意味着逻辑索引要倒着映射到物理存储（最后一个逻辑元素在最前面的物理地址），这条语义和正步长的映射方式不同，必须单独分支，不能和正步长场景混在一套 offset 计算里。

分类之后，在真正的 strided 场景内部，进一步按"每核平均分到的元素数"分两条腿：

• 数据量很小、每核分不到 CAXPY_STRIDED_SCALAR_MAX_PER_BLOCK（16）个元素时，走 STRIDED_SCALAR——用双缓冲/流水线的开销比数据量本身还大，标量逐元素处理更划算。
• 数据量足够大时，才值得上流水线，此时再分 shared 和 disjoint 两种 tile 策略（见下）。

这一层分类判断本身不涉及任何具体的性能调优，只是把 BLAS 语义要求的步长组合按访存代价归类，让后面的 kernel 选择逻辑（SelectCaxpyKernelVariant）能对"这批数据该用哪种搬运方式"做出针对性判断，而不是所有非稠密场景共用一个保守兜底实现。

在此基础上的性能优化：动态共享跨度流水线

shared span-read pipeline 的可用范围从固定 |incx|<=9 改为运行时动态计算的 CaxpySharedTileCapacity(|incx|)，tile 容量随 |incx| 收缩以保证跨度读取仍落在 38KiB lowScratch 缓冲区内：

tileCapacity = min(512, floor((38912/8 - 1) / |incx|) + 1)

通过 CaxpyTilingData.sharedTileCapacity 把这个运行时容量从 host 传到 device，shared pipeline 的 ping-pong 加载/计算/存储改用该值而非硬编码 512；disjoint 路径不受影响。

最终派发再叠加一个实测得到的性能上限 CAXPY_SHARED_SPAN_PERFORMANCE_MAX_INCREMENT=60：incx<=60 走 shared，incx>=61 走 disjoint。同设备、同 Release 构建、n=1048576 稳态 A/B 测得 incx=16/32/41 比 disjoint 快约 10%~18%，incx=50/55 快约 4%，incx=60 附近打平，incx=150 在这个上限之外维持在旧基线噪声范围内（约 490µs）。

测试基础设施迁移

原分支的功能测试是硬编码 C++ 数组 + 手写 main()。核对同为 arch22 complex level-1 算子的邻近实现后发现，仓库里更新的算子（如 cdgmm）已经统一改用 CSV + GoogleTest 参数化用例（GetCasesFromCsv + BlasTest<Param> fixture），本次交付照此约定把 CAXPY 的测试迁移过去：拆出 caxpy_param.h（CSV 行解析）、caxpy_golden.h（host 端参考实现）、caxpy_npu_wrapper.h（设备内存管理封装）、caxpy_test.csv（原 78 个用例 1:1 迁移，覆盖 dense/strided/负 stride/多核/多wave/shared-tile-tail 及本次新增的动态阈值边界）。

关联的Issue

无（功能补充 + 性能优化 + 测试基础设施对齐，非 Issue 驱动）。

测试

• 基线：upstream/master（官方 cann/ops-blas），release 分支从此处拉平并 squash 为若干阶段性提交（功能实现 / UB 布局重构 / 动态 tile 性能优化 / 50 行函数限制重构 / CSV 测试迁移）。
• 每次改动均在最终精确 commit 上从零 git archive + 容器内解压 + Release 构建 + 运行，不复用早期或未 squash 分支的测试结果作为证据。
• 最终验证（Ascend 910B3 / CANN 9.0 A3，容器 cann9-a3-test-priv，Release 构建）：
  • caxpy_test：80/80 通过（78 个 CSV 参数化用例，覆盖上述全部 stride 分类及正负步长组合 + 2 个 null 校验用例）。
  • caxpy_dispatch_policy_test：独立运行 EXIT_0。
  • git diff --check 无空白错误；git diff upstream/master caxpy-release 仅覆盖 CAXPY 相关文件。
• 性能证据（同设备，Release 构建，warmup=200 iterations=2000，n=1048576 稳态）：
  • incx=16/32/41：动态 shared 比旧固定阈值 disjoint 快约 10%~18%。
  • incx=50/55：快约 4%。
  • incx=60：噪声范围内持平（cross-over 点）。
  • incx=150：回到旧基线噪声范围内（约 490µs vs 502µs）。

文档更新

无独立文档改动；stride 分类依据、动态容量公式、性能上限的来源已作为代码注释写入 caxpy_dispatch_policy.h 和 caxpy_kernel.cpp。

类型标签

• Bug修复
• 新特性
• 性能优化
• 文档更新
• 其他，请描述：