docs(plan): Task3 的 MAX_OPS 接线加 cpu_limit=0 守卫

Task 2 代码质量评审建议：cpu_limit=0 的后果是所有法术静默零步，症状离根因极远。
spell_evaluator 的读取点是该故障唯一可观测处，能同时兜住 attributes.json 缺失
与 add_modifier 的 attr_id 打错两种上游失败——根因处的报错够不到这两种。
maxi(...,1) 使故障下游戏仍可玩而非完全瘫痪。

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

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

@@ -380,9 +380,16 @@ EOF
 改为
 ```gdscript
 	# 生效 cpu_limit 已含法杖份额（combat_manager 以 source="core" 的加成接入）
-	var max_ops:           int = MAX_OPS_PER_CPU * PlayerStats.cpu_limit
+	# 0 守卫：cpu_limit=0 意味着所有法术执行零步、全局静默失效。此处是该故障唯一可观测处，
+	# 能同时兜住上游两种失败（attributes.json 缺失 → 裸字段停在 0；add_modifier 的 attr_id 打错 →
+	# "core" 份额没注入），而根因处的报错够不到这两种。
+	if PlayerStats.cpu_limit <= 0:
+		push_error("SpellEvaluator: PlayerStats.cpu_limit=%d，法术将无法执行；检查 attributes.json 与 _rebuild_wand 的 core 加成注入" % PlayerStats.cpu_limit)
+	var max_ops:           int = MAX_OPS_PER_CPU * maxi(PlayerStats.cpu_limit, 1)
 ```
 
+> **为什么在这里也守一道**（Task 2 代码质量评审建议）：`cpu_limit = 0` 的后果是「所有法术静默什么都不做」—— 症状离根因极远。而这里是它变得**可观测**的地方，一条 `push_error` 就能指向真正该查的两处。`maxi(..., 1)` 使游戏在故障下仍可玩（退化为 40 步）而非完全瘫痪。
+
 - [ ] **Step 2: 移速改读属性**
 
 `player_manager.gd`：删除 `:7` 整行 `const MOVE_SPEED:          float = 200.0`；把 `:45` 的