[MEDIUM] CalcRes 新增分支未守护 topoLevelNums，多级拓扑下 AicpuReduceSoleNHR 将因跨 pod 链路非 UB_CTP 而建链失败

问题分析：

• 第 39 行分支条件只判断 level0Topo == MESH_1D_CLOS && !level0PcieMix，未限制单级拓扑。
• AicpuReduceSoleNHR 在多级拓扑下同样会被选中（reduce_auto_selector.cc 第 299 行 Level1Nhr（layer0 实例数 GCD==1）路径），此时 TopoMatch1D 会把 infos[0][0] 填成全量 rank，NHR 环上对端可能跨 pod。
• CalcChannelRequestNhrMultiJetty（channel.cc）只接受 linkAttr.linkProtocol == COMM_PROTOCOL_UB_CTP 的链路，跨 pod 链路通常为 UBOE/ROCE，匹配不到时直接报 "there is no link" 返回 HCCL_E_INTERNAL。
• 旧路径 CalcChannelRequestNhr 走 GetProtocolByEngine（UB_CTP/PCIE/UBOE 多协议）可跨 pod 建链；本 PR 改动后该场景由可用变为直接报错。

建议修复： 分支条件增加单级拓扑守护（与 SelectMeshAlgoAicpu 仅在 topoLevelNums<=1 时被调用的语义对齐）：

if (topoInfo->level0Topo == Level0Shape::MESH_1D_CLOS && !topoInfo->level0PcieMix
    && topoInfo->topoLevelNums == 1) {

若确认 Level1Nhr + MESH_1D_CLOS 组合不可达，请在注释中说明依据。

[MEDIUM][复检] 回复称"已在注释说明"，但当前 head 未找到该注释

复检事实：

• 实读 head 8c54062b0 的本文件：第 39 行仅有 // UBX机型 & PCIE机型判断，grep 全文件无 Level1Nhr / 单级拓扑 / 不可达相关注释，与回复"已在注释说明"不符。
• 技术依据本身经核验成立：SelectMeshAlgoAicpu 仅在 topoLevelNums<=1 时被调用（SelectAicpuAlgo 的 else 分支）；多级拓扑下 MESH_1D_CLOS 实例尺寸对称（GCD>1）时 Level1Nhr=false，选择链最终 NOT_MATCH，不会实例化 ReduceNHR。

建议修复（二选一，成本都很低）：

• 按回复所述补一行注释，把依据留在代码里：

// MESH_1D_CLOS 层0 CLOS/MESH 实例尺寸对称（GCD>1），Level1Nhr 不可达；本分支仅单级拓扑可达
if (topoInfo->level0Topo == Level0Shape::MESH_1D_CLOS && !topoInfo->level0PcieMix) {

• 或直接补守护，防御性更强：分支条件追加 && topoInfo->topoLevelNums == 1。

[MEDIUM] 每对端多条 UB_CTP 通道被全部申请但只使用 at(0)，造成通道资源浪费

问题分析：

• 第 41-46 行调用 CalcChannelRequestNhrMultiJetty，该函数按 multi-jetty 设计可为每个对端返回多条通道（兄弟模板 InsTempAllReduceNHR/InsTempReduceScatterNHR 均按 channelsPerRank 建多线程消费，MAX_JETTY_NUM=4）。
• ReduceNHR 的线程模型固定单线程：第 33-36 行 threadNum=1、GetThreadNum() 恒返回 1；KernelRun 中（第 188/189/243/244 行）channels.at(...).at(0) 只取每个对端的第一条通道。
• 若此拓扑下每对端返回多于一条通道，resourceRequest.channels 中多出的通道会被资源层真实创建（占用 jetty/notify 等设备资源）但从不使用，放大通道占用。

建议修复： 若本意只是换选路（选 port 127 的 CLOS UB_CTP 通道），建议每个对端只保留一条，例如过滤时跳过 remoteRank 已存在的通道；或按实际通道数对齐线程模型（参考 InsTempAllReduceNHR 的 channelsPerRank_ 做法）。