补读改写耗时基准，以及 kvspace·cp / cpdir 教程（#330）

[carsontung666]

#330 里先合这两块，runtime 不动。

• bench/iops：同一段 a = a + 1，Rust、Python、kvspace 各跑一遍，看一次读改写要多久。kv.c 按当前接口写，Get 之后用 WriteInPlace，写不进去再 WriteNewPlace。
• bench/baseline.md：改性能之前记下的一组数。
• tutorial/13-stdlib/kv/cp.kv、cpdir.kv：给现有的 kvspace·cp、kvspace·cpdir 补教程。

[miaobyte]

这个 PR 同样带上了 #329 的 head 改动，回归同样是 FAIL:217

分支	test-fs	test-shm
master	PASS:214 FAIL:3	PASS:213 FAIL:4
本 PR	PASS:0 FAIL:217	fail

本 PR 的三份文件与 #351 字节级完全相同：

runtime-rs/src/engine.rs      | 64+ 12-   （与 #351 相同）
runtime/src/runtime_internal.h|  4+  0-   （与 #351 相同）
runtime/src/xvalue.c          |152+  0-   （与 #351 相同）

即本 PR = #351 的 head 改动 + bench/iops + tutorial/13-stdlib/kv/{cp,cpdir}.kv 的增量。详细定位与复现步骤见 #351 的评论（根因在 runtime/src/xvalue.c 的 box64 编码器与 runtime/src/kvspace.c:529 的 kvspaceDecodeHead 不兼容）。

建议拆开

#329 目前仍是 OPEN 的 RFC，head 格式的归属方是 kvspace，而 kvspace 侧当前仍是可变长 head（kvspace.h 顶部注释为权威定义）。在格式定案之前，#329 的改动不适合混进性能 PR。

本 PR 里真正独立、且与本回归无关的部分：

• bench/iops/* 微基准与 bench/run.sh
• bench/baseline.md、bench/v0.3.md、bench/issue-330-progress.md
• tutorial/13-stdlib/kv/cp.kv、cpdir.kv
• .gitignore

建议把这三份 runtime 文件从本 PR 摘掉、只留上述内容，这样可以独立评审合入；#329 的 head 改造单独走一个 PR，等格式在 kvspace 定案后再推进。

[carsontung666]

已按评论处理：

• 三份 runtime 文件（runtime-rs/src/engine.rs、runtime/src/runtime_internal.h、runtime/src/xvalue.c）已回到 master，本 PR 不再带 [RFC] 0-kvspace: XValue head 重定：ref int8 多级指针 + storetype 收缩为 (bodycap,valuelen) + langtype 定长 #329 的 box64 head。
• 剩下独立内容：bench/iops 微基准与 before-after、tutorial/13-stdlib/kv/{cp,cpdir}.kv、.gitignore。
• tutorial 里误写的 kv·cp / kv·cpdir 已改成与同目录其它用例一致的 kvspace·cp / kvspace·cpdir。

#329 的 head 改造单独留在 #351，等 kvspace 格式定案后再推进。

[carsontung666]

又收了一遍，提交历史已 rebase 成一条，不再带 #329 的 runtime 文件：

• 恢复 .gitignore 里误删的 shm/tutorial 规则，只新增 bench/iops/.run/
• 删掉本地进度稿 bench/issue-330-progress.md、bench/v0.3.md，以及依赖 kvspace-c/src + 64-byte head 的 kv_inplace.c
• run.sh 不再默认 build-head64 / build-pr330
• 本 PR 无 runtime 改动

[miaobyte]

三块都落在实处，说几点具体的。

1. baseline 的冻结纪律——标题直接写 "do not treat as an improvement"，并且明确声明 #204 的 695.8 ns/iter 与 #194 的 33.37 s "is not this baseline"。这条我特别认可：基准的全部价值在跨时间可比，一个从 issue 里引来的旧数字会立刻把它变成不可比的噪声。把 host / DSN / 日期钉死、把"引用数字 ≠ 本基线"写明白，是让后面所有优化收益变成可判定命题的前提。

2. 三语言量同一段 a = a + 1——Rust 1.361 / Python 49.319 / kvspace 168.938 ns/iter。把"一次读改写"的地板单独切出来，等于把"慢"这个笼统说法拆成可归因的项：解释循环 vs KV 往返。这比端到端跑一个程序有信息量得多。

3. kv.c 按真实接口写，而不是按理想接口写——Get 走借用（不得 free）、写走 WriteInPlace 失败再 WriteNewPlace、注释还记下 v0.2.18 没有 kvspaceSet/kvspaceBytesFree。基准若跑的是理想路径，得到的就是乐观的假地板；这里量的是 runtime-c 实际走的那条路，数字才有资格当参照。

cp.kv / cpdir.kv 补得也正好——这两个算子在 tutorial 里此前是零覆盖，而且 cpdir 的路径形式（/cptree 而非 /cptree/）不直观，"拷贝产出独立副本"这条语义一直没有锚例固定。现在有了。

最后那句 "PC remains a kvspace path (·pc); this freeze does not add a process-private PC" 是有分量的一句：它提前挡掉了"为了基准好看而引入进程私有 PC"这条捷径。

一句上下文，供参考：master 现在的红不是这个 PR 带来的（它的文件全部通过），而是刚落的锚例在驱动实现——04-ndarray/array_append.kv、array_slice.kv、13-stdlib/duration/sub.kv 这几条按 spec 应当通过、当前不通过；另有 07-lib/walk_lib.kv、13-stdlib/kvlang/01-reflect.kv 两例在查。

prime_sieve 那行已经把目标量级摆在台面上了。有了这份冻结基线，下一步优化是不是真的改善，就有据可判了。继续。