What type of PR is this?

/kind feature

What does this PR do / why do we need it:

本 PR 为已有的 Qwen3.5 Linear Attention Context Parallel 增加显式可选的 Triton-Ascend
Gated Delta Rule（GDN）融合后端，并为 State-P2P 模式增加融合的状态仿射 summary 路径。

主要改动如下：

1. 增加 GDN Triton-Ascend 前反向算子，覆盖 token output、final state、全部输入梯度以及
   initial/final-state gradient。
2. 增加 State-P2P 所需的 state summary、summary apply 和反向 gradient-summary 算子，
   将跨 rank 依赖收敛为较小 recurrent state 的传递，避免传输完整序列激活。
3. Ulysses 和 P2P 均可通过 linear_attention_gdn_backend: triton 显式启用融合后端；默认
   仍为 eager，不改变已有配置的行为。
4. 对 Triton 版本、设备、dtype、head dimension、chunk size、local sequence 和 CP mode
   进行 capability 检查；不支持的组合直接报错，不进行静默回退。
5. 保持 AllGather Triton、融合 Conv1D 和自动 backend 选择不在本 PR 范围内；
   all_gather + eager 仍按已有实现工作。
6. 增加 wheel 打包规则和第三方许可证文件，并保证 CPU/MindSpore import 不会主动加载
   Torch Triton kernel。

该功能用于解决 eager GDN 由大量小算子及长 autograd graph 带来的性能和显存问题，并使
P2P Linear Attention CP 在长序列和较大 CP size 下避免 Ulysses 的大张量 all-to-all 以及
head 分片后 kernel 并行度下降问题。

Which issue(s) this PR fixes:
完整的测试验证报告见关联的issue #320

Test Plan and Test result：What scenarios were tested, and what were the verification results（Function, performance, reliability, etc.）：

测试环境：8 张 Ascend 910B3，CANN 9.1.0-beta.3，PyTorch 2.10.0，torch-npu 2.10.0，
triton-ascend 3.2.1，主要计算类型为 BF16，GDN gate 累计及 recurrent state 使用 FP32。

性能统一使用 warmup=5/repeat=20；计时前后执行 barrier/device synchronize，并取所有 rank
elapsed 的最大值，报告 median/min/p90。显存取所有 rank 的 peak allocated 最大值。

1. 单卡 GDN 算子精度、性能和显存

   • Shape：B=1,H=32,dk=dv=128，序列长度 8K/16K/32K；覆盖有/无 initial state、
     三个随机种子以及随机 dO/dHT。
   • 对比 eager reference 的 output、final state、dq/dk/dv/dg/dbeta/dH0，最差
     relative-L2 为 5.86e-3，全部张量 finite，误差未随序列长度增长。
   • Triton 相对 eager 的 Fwd+Bwd 加速为：8K 12.65x、16K 22.37x、
     32K 40.08x、64K 74.17x；增量 peak allocated 均降低约 3.84x。
     64K 仅补测性能和显存。该数据只代表 GDN core，不代表完整层或整网收益。

2. CP4 完整 Linear Attention 层功能和精度

   • 覆盖 projection、Conv1D CP halo、Q/K L2Norm、GDN、RMSNormGated 和 out projection。
   • 配置：hidden=2048,QK/V heads=16/32,head dim=128,BF16；无 CP eager 层作为
     reference。
   • Ulysses Triton、P2P Triton 和 AllGather eager 均完成 8K/32K 前反向对齐；
     P2P Triton 在 32K 下 output/input-grad/parameter-grad relative-L2 分别为
     4.4771e-3/5.8587e-3/5.0757e-3。
   • 使用 B=2,global sequence=8192,valid length=7777 验证尾部 padding、跨 rank
     mask 切片和 GDN partial chunk；三种模式的 padding output 均为 exact zero。
   • 连续执行至少 20 次分布式前反向，无 P2P 顺序错配、死锁、NaN/Inf 或显存持续增长。

3. 四层 Qwen3.5 多步训练精度

   • 模型：3 层 Linear Attention + 1 层 Full Attention，hidden=2048，BF16，AdamW，
     非零学习率；每一步读取不同的真实 token 序列。
   • CP4 + FSDP group 4 完成 100 个 optimizer steps；CP8 + FSDP group 8 完成
     200 个 optimizer steps，并覆盖七跳 P2P 状态链。
   • Ulysses/P2P 的最大 loss relative diff 均低于 3.8e-4，最大 grad-norm relative
     diff 为 3.8e-3~4.0e-3；全部步骤无 NaN/Inf、无误差持续扩大。
   • AllGather eager 额外完成 10 步功能回归，最大 loss/grad-norm relative diff 分别为
     8.19e-5/2.87e-4。

4. 完整层性能和显存

   Topology	Global/local seq	P2P Fwd+Bwd time reduction vs Ulysses	Peak allocated
   CP4	32K/8K	14.4%	P2P +12.0 MiB
   CP4	64K/16K	17.0%	P2P +12.0 MiB
   CP8	64K/8K	31.6%	P2P -52.1 MiB
   CP8	128K/16K	45.8%	P2P -116.2 MiB

5. Qwen3.5 整网性能和显存

   Topology	Model	Global/local seq	P2P Fwd+Bwd time reduction	Throughput increase	Peak allocated reduction
   CP4 + FSDP4	4 layers	64K/16K	8.83%	9.69%	372 MiB
   CP4 + FSDP4	8 layers	64K/16K	9.31%	10.27%	744 MiB
   CP8 + FSDP8	4 layers	128K/16K	15.94%	18.96%	372 MiB / 2.38%
   CP8 + FSDP8	8 layers	128K/16K	15.84%	18.82%	744 MiB / 2.47%

   完整层收益进入整网后会被 MLP、Full Attention、embedding、lm_head、loss 和 FSDP
   等公共开销稀释。CP4/64K 四层整网仍保留约 92% 的三层 Linear Attention 绝对节省；
   CP8 下 Ulysses 的 all-to-all 和小 head kernel 开销进一步增加，因此 P2P 整网收益扩大到
   约 15.9%。

6. Profile、兼容性和工程检查

   • CP4/64K Level0 profile 中，单次 P2P send 约 0.12~0.14 ms；中间 rank 存在
     计算通信重叠，状态张量传输带宽不是主要瓶颈。
   • backend=auto、all_gather + triton、不支持的 head dimension/chunk size/local
     sequence，以及 Triton 缺失或版本不满足时，均按预期 fail-fast。
   • Linear Attention CP CPU UT：10 passed。
   • git diff --check、pylint/lizard 流水线、wheel 构建及隔离安装检查通过；wheel 中包含
     GDN kernel 和许可证文件。

Self-checklist:（请自检，在[ ]内打上x，我们将检视你的完成情况，否则会导致pr无法合入）

• 设计：PR对应的方案是否已经经过Maintainer评审，方案检视意见是否均已答复并完成方案修改
• 测试：PR中的代码是否已有UT/ST测试用例进行充分的覆盖，新增测试用例是否随本PR一并上库或已经上库
• 验证：PR描述信息中是否已包含对该PR对应的Feature、Refactor、Bugfix的预期目标达成情况的详细验证结果描述
• 接口：是否涉及对外接口变更，相应变更已得到接口评审组织的通过，API对应的注释信息已经刷新正确
• 文档：是否涉及官网文档修改，如果涉及请及时提交资料到Doc仓（本 PR 不涉及官网文档修改）