docs(plan): 补跑守卫的另外三条进入路径，六条全部由运行时而非眼读覆盖

resume_game / _apply_padded(买卡) / apply_wand_save_data 三条原本只经静态核对，
现已在运行时跑到：均 0 条 cpu_limit=0 报错，且 deck/属性状态正确。
连同已跑的 start_game / switch_core / combat_test，六条齐全。

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

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

@@ -980,12 +980,17 @@ Run: godot-mcp-pro `stop_scene`，然后 `execute_editor_script` 扫四个文件
 
 先决条件是 Step 1b（否则观测为空）。观测结果：
 
-| 入口路径 | 观测 | 结果 |
-| :-- | :-- | :-- |
-| `start_game`（`play_scene` 开局） | Debugger 错误页 | 0 条 `cpu_limit=0`，`cpu_limit=5` |
-| 商店「法杖」按钮 ×4（轮换覆盖全部 5 把杖） | 同上 | 0 条；抽样点 `wand_basic`=5、`wand_fast`=3、`matrix_board`=8，`_modifiers` 恒 1 条（`wand_memory`/`circuit_fork` 两次未逐个抽样 `cpu_limit` 值，但同样 0 条报错——守卫若被触发会留痕） |
-| `combat_test.tscn`（独立会话） | 同上 | 0 条，`cpu_limit=5` |
-| **正对照**：手动 `remove_modifiers_from("core")` 后调 `equip_wand` | 同上 | ✅ **报了 1 条** `player_manager.gd:98 @ equip_wand(): PlayerManager: 装备「小木法杯」后 cpu_limit=0…` |
+复审静态核对过的六条进入路径，**全部**在运行时跑到了：
+
+| # | 入口路径 | 怎么跑到的 | 结果 |
+| :- | :-- | :-- | :-- |
+| 1 | `start_game` → `_transition_to_battle` | `play_scene` 开局 | 0 条，`cpu_limit=5` |
+| 2 | `resume_game` → `_transition_to_battle` | `ProfileManager.save_run()` 后调 `resume_game()` | 0 条，`cpu_limit=5`，deck 正确恢复 |
+| 3 | `switch_core` | 商店「法杖」按钮 ×4，轮换覆盖全部 5 把杖 | 0 条；抽样 `wand_basic`=5、`wand_fast`=3、`matrix_board`=8，`_modifiers` 恒 1 条 |
+| 4 | `_apply_padded`（`install_spell`） | 商店买一张 Spark Bolt | 0 条，`cpu_limit=5`，deck 变 2 张 |
+| 5 | `apply_wand_save_data` | 由路径 2 的 `ProfileManager.apply_run` 带到（其自身不调 `equip_wand`） | 0 条 |
+| 6 | `combat_test.gd` | `play_scene combat_test.tscn`（独立会话） | 0 条，`cpu_limit=5` |
+| — | **正对照**：手动 `remove_modifiers_from("core")` 后调 `equip_wand` | 故意制造 `cpu_limit=0` | ✅ **报了 1 条** `player_manager.gd:98 @ equip_wand(): PlayerManager: 装备「小木法杯」后 cpu_limit=0…` |
 
 正对照是这一步的关键：它证明守卫**是活的**，因此"其余路径 0 条"才有信息量。整场会话（约 13 分钟）的运行时报错逐条清点后**全部**能归因到本次验收自身（故意探针 + MCP 注入脚本的解析告警），无一条来自游戏代码的意外路径。