[MEDIUM] memDesc 线格式追加 pid 但无版本/魔数标识，旧格式描述符会被静默错位解析

GetMemDesc 将 memDesc 线格式从 [dto][EndpointDesc] 扩展为 [dto][EndpointDesc][pid]，但线格式没有引入任何版本/魔数标识，本处仅以 descLen < tailLen 做长度下界校验，无法区分新旧两种格式。

旧格式（未追加 pid）的 memDesc 只要 dto 长度 >= 4 字节即可通过该校验，随后被静默错位解析：末尾 4 字节（实为 EndpointDesc 尾部）被当作 pid，EndpointDesc 整体向后偏移 4 字节，dto 被截断 4 字节。结果是按错误的 (endpointDesc, pid) 建 key、以错误的 addr/size 导入远端内存，且无任何报错（不满足 fail-fast）。

建议：

1. 在 memDesc 中增加版本/魔数字段（如固定魔数 + 版本号），解析时先校验；
2. 或先反序列化 dto 得到 dtoLen，再校验 descLen == dtoLen + sizeof(EndpointDesc) + sizeof(uint32_t)，使旧格式能被干净地拒绝而不是静默错位解析。

[MEDIUM] key 维度扩展、加锁、空 Mgr 清理等行为变更无任何 UT 覆盖

第 207 行：HcclResult RoceRegedMemMgr::MemoryImport(const void* memDesc, uint32_t descLen, HcommMem* outMem)

问题分析：本 PR 引入三处行为变更——①remoteRdmaRmaBufferMgrs_ 的 key 从 EndpointDesc 扩展为 (EndpointDesc, pid)；②MemoryImport/MemoryUnimport 新增 memMtx_ 互斥保护；③MemoryUnimport 在 Del 后对空 RemoteRdmaRmaBufferMgr 做 erase 清理（roce_mem.cc:273-275）。但 git diff 显示 test/ 目录零变更，PR 模板「补充的UT用例」栏也是空的。experimental/base_comm 参与编译链接（cpu_roce_endpoint.cc 直接构造 RoceRegedMemMgr），上述逻辑的正确性（尤其 Import/Unimport 的 key 对称性与清理时机）完全依赖人工验证，后续重构无回归防护。

修复建议：补充 UT 用例（建议放 test/ut/framework/next/comms/endpoints/reged_mems/ 下，仿 ut_roce_mem_test.cc 的 mockcpp 模式，对 experimental 版另建文件）：

1. 同 endpointDesc、不同 pid 的两次 MemoryImport，断言 remoteRdmaRmaBufferMgrs_ 生成两个独立 Mgr 条目、互不影响 Add/Del；
2. MemoryUnimport 把某 Mgr 的最后一个条目删空后，断言该 remoteKey 从 map 中被 erase（size 变化用 #define private public 方式或新增计数接口断言）；
3. descLen 边界：descLen < sizeof(EndpointDesc)+sizeof(uint32_t) 时 GetParamsFromMemDesc 返回 HCCL_E_INTERNAL；
4. memDesc 末 4 字节 pid 与 EndpointDesc 的拼接顺序往返一致性（GetMemDesc 生成 → GetParamsFromMemDesc 解析还原同一 pid 与 endpointDesc）。

[MEDIUM] pid 作为远端进程唯一标识存在复用漂移风险，重启进程可能误拒导入或误删他人内存

第 34 行：uint32_t pid{0};

问题分析：RemoteRdmaMemKey 以 (endpointDesc, pid) 区分远端进程，pid 取自导出方 getpid()（roce_mem.cc:146）。Linux pid 是可复用的滚动编号：远端进程异常退出且未走 MemoryUnimport 时，本端 remoteRdmaRmaBufferMgrs_ 残留 key=(ep, pid) 条目；若新进程重启后拿到相同 pid 且 mmap 到与旧进程相同的地址区间（同二进制多次运行 VA 高度稳定），MemoryImport 中 Add(tempKey, ...) 会命中残留条目返回 HCCL_E_AGAIN，合法导入被误拒；反之框架延迟补发的 Unimport 会把新进程刚导入的同地址条目误删。容器/PID namespace 场景下不同远端容器进程 pid 撞号的概率进一步放大。

修复建议：

1. 优先方案：导出侧改用进程生命周期内单调唯一且跨重启不重复的标识，如 pid + 进程启动时间戳（读 /proc/self/stat 第 22 字段），或直接复用通信域已有的全局唯一 ctx/comm id；
2. 过渡方案：至少在 MemoryImport 的 Add 返回 false（HCCL_E_AGAIN 路径）时校验已存条目的 rkey 与本次 dto.rkey 是否一致（ExchangeRdmaBufferDto 含 rkey 字段），不一致说明是 pid 复用后的残留条目，应先清理旧条目再重新 Add，并在日志中告警；
3. 若维持现状，须在 RemoteRdmaMemKey 的注释中明确记录「pid 复用场景下条目可能误命中」的边界假设，供部署评估。