fix: guard P800 sdpa perf loading

[TruNcat3]

自查

• 核心八件齐全: README / REPORT / __init__.py（包化入口） / reference / register / example / kernel/ / test/（不新增算子；修复既有 P800 sdpa backend 与 perf 门禁）
• 三层测试绿: test/{kernel,op,framework}_level.py（P800 example.py p800-kunlunxin 三层通过）
• 性能对照: script/bench_perf.py（native 参照）+ reports/ 更新（修复 perf gate 本身并复测）
• 黄金绿: goldendata/ + script/check_accuracy.py（本 PR 不改变 sdpa 数值语义；P800 golden 397/397 已复验）
• 包化回归绿: python3 ops/test_packaging.py（全算子导入扫描 16/16）
• 多平台变更时: PLATFORM.md / MERGE.md 已同步（无新平台；MLU 仅同步同一 import 修复）
• 署名一致: wt-YYYY-MM-DD-fix + # wt <邮箱>，commit 作者相同（小范围工程修复）

说明

来自 PR #10 合入后的作者自查：多算子 perf registry 按顺序加载时，早先算子的顶层 reference 模块会遮蔽 ops.sdpa 的同名导入，导致：

ops.sdpa.p800.forward SKIP
ImportError: cannot import name 'sdpa_reference' from 'reference'

修复分两层：

1. ops.sdpa P800/MLU backend 改为包态相对导入优先，保留单算子脚本模式 fallback。
2. perf_run 在执行本次选中用例前清理对应旧 JSON；任一用例 SKIP 时直接返回失败，防止 perf_compare 消费历史成功记录形成假绿。

验证

pytest tests/unit -q                          23 passed
ops package import scan                       16/16
python3 ops/sdpa/example.py p800-kunlunxin    kernel 37 / op / framework 全绿
perf_run --pattern ops.sdpa                   4 records / 0 skip
ops.sdpa.p800.forward                         0.151ms, +1.3% vs baseline
perf_compare p800-kunlunxin                   FAIL 0 / WARN 0 / NEW 0
markdown / syntax / diff check                PASS

[TruNcat3]

Review 完成，本机（Ascend910 真机）验证通过，LGTM ✅

已验证：

1. 全量回归绿：tests/unit 23 passed / ops/test_packaging.py 16 目录 / ops/sdpa/example.py ascend910 三层全绿（kernel 37 case + op + framework）/ sdpa_math kernel 层绿——我们平台零破坏
2. 修复机制复现：本机模拟"外来顶层 reference 占据 sys.modules"场景（monkeypatch foreign module），ops.sdpa.kernel.backends.p800_kunlunxin 的 sdpa_reference 正确解析到 ops.sdpa.reference——修复有效，且与 feat: 算子目录包化——多算子同进程冲突根治（ops.sdpa / ops.embedding） #14 包化范式（包态优先+脚本态 fallback）完全同构
3. perf 门禁两处收紧方向正确：clear_run_records 防陈旧 JSON 假绿、n_skip==0 硬门。test_perf 两个新单测 + test_sdpa_backend_import 的遮蔽回归测试写得很好——这类"环境差异掩盖的缺陷"正是 CI 抓不到、单测能锁住的
4. import 顺序调换（包态 try 在前 / 裸 import 降为 ImportError fallback）与 embedding/sdpa_math 近期同类修复一致，方向统一

两个小建议（不阻塞合并，可 follow-up）：

• test_sdpa_backend_import.py 的 module = importlib.reload(module) 返回值被覆盖后未复用（第一行 import_module 已够），reload 是为防模块已缓存的场景——可加一行注释说明意图，避免后人误删
• mlu590.py 的同款 import 修复在本 PR 一并做了（MLU 机器复验时顺带确认 example.py mlu590 三层即可）

CI 三门绿 + 我们平台真机回归绿，可以合并。感谢快速响应 #16 审计线索——这个"perf registry 顺序加载遮蔽"的发现是 #13/#14 同源问题的又一处实例，已记入平台绑定知识。

[TruNcat3]

最终判定：OK，可以合并 ✅

结论依据（均为本机 Ascend910 真机实测，非推测）：

1. 修复机制有效——复现了 PR 描述的遮蔽场景（外来顶层 reference 注入 sys.modules），sdpa_reference 正确解析到 ops.sdpa.reference
2. 零破坏——全量回归绿：tests/unit 23 passed / ops/test_packaging.py 16 目录 / ops/sdpa/example.py ascend910 三层全绿（kernel 37 case）/ sdpa_math kernel 层绿
3. 门禁收紧方向正确——SKIP 即 FAIL + 预清旧 JSON，堵住历史记录假绿；且新增单测把遮蔽场景固化进 CI
4. CI 三门绿

边界声明：P800 真机 perf 数字（0.151ms / +1.3%）出自作者环境，本机无昆仑芯未复测——但修复不改 kernel 数值语义，该数字非门禁项。

两条不阻塞建议（reload 意图注释 / MLU 复验顺带确认）见上一条评论。合并后建议 follow-up：把这处"perf registry 顺序加载遮蔽"补进 sdpa PLATFORM.md 的绑定清单（与 #13/#14 同源问题的第三处实例）。

[TruNcat3]

Follow-up 已补：#23 记录 PLATFORM.md 绑定约束、解释 reload 意图，并把外来顶层 reference 遮蔽回归扩展到 P800/MLU backend。