docs: 订正 wand_fast 饱和点 0.05→0.0667；roadmap 关闭已决定项并澄清移速表述

【订正】wand_fast(0.25s) 的饱和点按公式 (1/60)/0.25 = 0.0667，不是 0.05。
numerical_design:21 的标注与它自己上一句的公式直接矛盾，spec/plan 另有三处同源
错误标注——均派生自一句口头转述，实测表里记的 0.0667 一直是对的。

结论也随之改对，不只是改数字：hard=0.05 使 wand_basic(饱和 0.0333) 与
circuit_fork(0.0278) 无无效区间，但 wand_fast 仍剩 [0.05, 0.0667) 这段买不到东西
（较原 hard:0.01 的 6.7 倍缩至 1.33 倍）。仍取 0.05 的理由：饱和点 = (1/60)/法杖
基准间隔，随杖而异，不存在对所有杖都最优的单一 hard——取 0.0667 让 wand_fast 干净
会使另两把杖够不到自己的饱和点，反而制造新的不可达区间。hard 数值不变。

顺带说明实测表里 wand_fast@0.0667 读到 2 帧的原因：采样点比真实边界 1/15 高 3.3e-5
(T 上高 8.3e-6 s)，再叠加整帧倍数多花一帧的浮点余量效应，故实际 1 帧上界略低于
0.0667。数据没错，是标签错了。

【roadmap】E3-① 下的 cast_delay_mod 条目仍记为「待人定」并指向两个选项，而该决定
已在 ba7c885 关闭——roadmap 是查「E3 还剩什么」的索引，留着会把已关闭的决定重新打开。
改为已处理，并注明彻底消除需让 hard 逐杖化（挪进 cores.json），属独立立项。

【roadmap】「实测 200→300 px/s」读起来像发版移速由 200 改成 300，与同批改动里
numerical_design 的订正（发版是 200，300 是从未被读过的纸面值）直接冲突。改写为
「发版基准仍是 200；实测手段是临时挂 +50% 加成使生效值变 300」。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs_dev/plans/2026-07-31-player-attributes.md

@@ -1015,8 +1015,8 @@ Run: godot-mcp-pro `stop_scene`，然后 `execute_editor_script` 扫四个文件
 | `wand_fast`（基准 0.25 s） | 1.0 | 0.25 s | 16 帧 | 3.75 /s |
 | | **0.1（soft）** | 0.025 s | 2 帧 | **30 /s** |
 | | 0.07 | 0.0175 s | 2 帧 | 30 /s |
-| | 0.0667 | 0.016675 s | 2 帧 | 30 /s |
-| | **0.05** | 0.0125 s | 1 帧 | **60 /s ← 饱和点** |
+| | 0.0667 | 0.016675 s | 2 帧 | 30 /s ← 采样点比真实边界 1/15 高 3.3e-5，故落在 2 帧侧 |
+| | **0.05** | 0.0125 s | 1 帧 | **60 /s ← 已在饱和区内（饱和点是 0.0667，非 0.05）** |
 | | **0.01（hard）** | 0.0025 s | 1 帧 | 60 /s |
 
 结论（供决策）：
@@ -1028,13 +1028,17 @@ Run: godot-mcp-pro `stop_scene`，然后 `execute_editor_script` 扫四个文件
 
 **两个选项曾提交人定**：(a) 保持 `hard: 0.01` 并在文档写明饱和区；(b) 把 `hard` 提到 ~0.05。
 
-**✅ 用户 2026-07-31 决定：采用 (b)，`hard: 0.01 → 0.05`。** 依据正是上表 —— `wand_fast` 恰在 0.05 饱和、`wand_basic` 在 0.0333 饱和，取 0.05 使两把主力杖都不再有「买了没用」的无效区间。落地三处：`data/attributes.json`、`numerical_design.md` §1.1、spec 新增 §2.2b（收录完整实测数据集）。
+**✅ 用户 2026-07-31 决定：采用 (b)，`hard: 0.01 → 0.05`。** 落地三处：`data/attributes.json`、`numerical_design.md` §1.1、spec 新增 §2.2b（收录完整实测数据集）。
+
+依据：饱和点 = `(1/60) / 法杖基准间隔` = `circuit_fork` 0.0278 / `wand_basic` **0.0333** / `wand_fast` **0.0667**。**该值随杖而异，故不存在对所有杖都最优的单一 `hard`**：取 0.05 使 `wand_basic` 与 `circuit_fork` 无无效区间，`wand_fast` 仍剩 `[0.05, 0.0667)` 一小段（从原来的 6.7 倍缩到 1.33 倍）；若改取 0.0667 让 `wand_fast` 干净，则 `wand_basic`/`circuit_fork` 反而够不到自己的饱和点，制造新的不可达区间。
+
+> **📌 订正（2026-07-31）**：本步初稿曾写「`wand_fast` 恰好在 0.05 饱和 / 两把主力杖都不再有无效区间」，**算错了** —— `(1/60)/0.25 = 0.0667` 而非 0.05。上方实测表里的 0.0667 一直是对的，错的是从口头转述派生的标注。`hard` 数值不受影响（0.05 仍是选定值，只是理由要说准）。
 
 **边界复测**（改动后用同一套扫描重跑，这是本次改动唯一的行为差异，值得实测而非推导）：
 
 | 法杖 | 请求 `mod` | 生效 `mod` | T | 实测帧距 | 速率 |
 | :-- | --: | --: | --: | --: | --: |
-| `wand_fast` | 0.05 | 0.05 | 0.0125 s | **1 帧×179** | 60 /s（恰好饱和，不浪费）|
+| `wand_fast` | 0.05 | 0.05 | 0.0125 s | **1 帧×179** | 60 /s（已入饱和区；饱和点是 0.0667，故 `[0.05, 0.0667)` 仍是无效区间）|
 | `wand_fast` | 0.01 | **0.05** | 0.0125 s | 1 帧×179 | 60 /s（`maxf(hard,…)` 钳制生效）|
 | `wand_basic` | 0.05 | 0.05 | 0.025 s | **2 帧×89** | 30 /s |
 | `wand_basic` | 0.01 | **0.05** | 0.025 s | 2 帧×89 | 30 /s（钳制生效）|