2-runtime 经验：vmkv.cpp 拆分致 run_frame 变小 → fib shm 4.7× 布局回退 #539

结论：环境相关误报（master d21743b 无回退）——已关闭

误报背景（2026-11 coding3 在旧 base 上实验）：coding3 在本地 HEAD=b50fd53（未拆分，vmkv.cpp 3251 行 else-if）时执行 runtimec2-vmkv-split.md 拆分，测得 fib 155µs(旧) → 735µs(拆分) 的 4.7× 回退，做了大量布局排查（15+ 手段）。

实际真相：master 后来更新到 d21743b（已含 native 段拆分：vmkv.cpp 2421 + vmkv_native.cpp 1736 + vmkv_native.hpp 45）。架构师在其 pod（Xeon 8336C 2.30GHz）用 git archive HEAD runtimec2 runtime/include 干净构建 master，隔离测 fib：n=8 155.75µs / n=9 217.9µs / n=10 321.7µs——与拆分前 b50fd53 的 155µs 一致，无回退。

coding3 在本 pod（同为 8336C 型号但物理机/步进可能不同，或构建链差异）干净构建 master 实测 fib n=8 = 723µs。同一 commit 不同 pod 4.7× 差异 → CPU 微架构（uop-cache/分支预测）对机器码布局的敏感，非 master 拆分问题。

经验（保留「经验」标签）：

1. 拆分执行前必须先确认本地 base：coding3 实验时本地 HEAD 是旧 b50fd53，但 master 已合并拆分（array 双形态迁移（compactarray / scatterarray）+ runtimec2 run_frame 拆分 #540 array-dual-form + 拆分提交）——在旧 base 上重复实验得到误导性"回退"。
2. 跨 pod 性能对比不可直接作准：同一 commit 在不同 pod（同型号 CPU 不同步进）实测可差 4.7×，fib 类深度递归基准对机器码布局极端敏感。
3. git archive HEAD 干净构建是排除旧增量 build 污染的标准手段（架构师裁决流程）。

动作：master 拆分保留，无需回退。coding3 实验残留已请 gitter 清理对齐 master。