加载器联测加强 + Sodium 诊断探针

## tests/test_loader_render.py

★ 划清本文件的**射程**（诚实标注）：
它证明的是「Knot 能被我们驱动，且在加载器下渲染能力照常」。
它**不**证明「真实 mod（带 mixin 的）能工作」—— 因为它用空 mods 目录。

  实测原因：真实 mod 的 mixin 目标是 intermediary 名，而我们跑 named
  ⇒ 同一 JVM 只能一个命名空间 ⇒ 真实 mixin mod 在本路线下不生效。
  ⇒ 「加载器能起动」与「mod 能用」是**两件事**，别把前者读成后者。

这条注释是被自己坑出来的：早先那份 6/6 全绿的报告，
读起来像"加载器路线可用"，实际只验证了"Knot 能起来"。

## tools/probe_sodium.py

诊断脚本：在装了 Sodium 的实例上跑一次注入 + debug，
打印它自己的状态（chunkStatus / chunkReady / loadQueue / rebuildQueue /
visibleChunks / chunksDebug），并出一张图。

★ 为什么需要它：vanilla 的 `countRenderedChunks()` 在 Sodium 下
  **永远返回 0**（它数的是 vanilla 的网格），光看这个数会把
  「换了渲染器」误判成「没有数据」。而 blockinfo 能读方块 ⇒ 数据是在的。
  ⇒ 排障必须问**渲染器自己**，不能问 vanilla 的计数器。

（debug 命令里的 sodium* 字段就是这条思路的落地：
  sodiumLoaded / sodiumTracker_chunkStatus / sodiumTracker_chunkReady /
  sodiumRebuildQueue / sodiumChunksDebug …）

tests/test_loader_render.py

@@ -7,9 +7,19 @@
   世代（1.20.1 / 1.21.1） × 启动架构（裸启动 / fabric）
 本文件专测第二个轴 —— `launcher="fabric"`。
 
-★ 为什么必须有这个文件
-  上一个会话把 `launcher="fabric"` 写进了后端，却**没有留下任何可重跑的验证** ——
-  「经加载器能起来」这件事只活在对话里。这个文件把它变成可复算的。
+★★ 本文件的射程（诚实地划清）
+
+它证明的是 **「Knot 能被我们驱动，且在加载器下渲染能力照常」**。
+它**不**证明「真实 mod（Iris/Sodium 等带 mixin 的）能工作」——
+因为这里用的是**空 mods 目录**。
+
+实测原因（2026-09-26，见 test_mixin_namespace_is_incompatible）：
+  真实 mod 的 mixin 目标是 **intermediary** 名（`net.minecraft.class_310`），
+  而我们的代码跑在 **named** 命名空间（`net.minecraft.client.Minecraft`，
+  由 `-Dfabric.gameMappingNamespace=named` 指定）。
+  ⇒ 同一 JVM 只能一个命名空间 ⇒ 真实 mixin mod 在本路线下**不会生效**。
+
+所以「加载器能起动」与「mod 能用」是**两件事**，别把前者读成后者。
 
 需要（缺任一项则跳过，不误报失败）：
   - MCFOLD_RENDER_CLASSPATH（含 client-named.jar 与编译产物）