refactor(attr): cpu_limit 守卫移至换杖处；cast_delay_mod 改在开火时生效

守卫从 execute_compiled 搬到 equip_wand：诊断应放在能导致故障的状态转换处，
而非 2 次/秒的使用点——施法端刷屏会埋掉根因，换杖处每局只跑几次且拿得到杖名。
maxi(..., 1) 保留：错误已在换杖处大声报出，退化不再静默，而去掉它会让法术硬瘫。

订正原注释的事实错误：它声称兜住「attributes.json 缺失」与「attr_id 打错」，
但这两种 player_stats.gd:173/191 早已各自报错，守卫零覆盖。真正无人管的是
「新调用点忘了注入」（正是 combat_test 修前的样子）与「cores.json 某杖配成 0」。

cast_delay_mod 由 equip_wand 快照改为开火时相乘：_cast_timer 语义两种写法一致
（总是从上次写入值倒数），代价仅每次施法一次浮点乘法，但「下一个周期」由下次
换杖变为下次施法——玩家买急速道具期待的是后者。随之删去解释延迟生效的注释。

另在 _rebuild_wand 注入处记下 remove-before-add 为何 load-bearing：漏了会让
cpu_limit 随 install_spell 累积，而 hard: 50 会把它封成一个看起来合理的数字。

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

scripts/domain/combat/combat_manager.gd

@@ -270,6 +270,8 @@ func _rebuild_wand() -> void:
 			leech += float(n.meta.get("mana_leech", 0.0))
 	PlayerStats.mana_leech = leech
 	# 法杖运算力以加成来源接入（非调用点相加），使 hard 上限作用于生效总值
+	# remove 必须在 add 之前：本函数每次 install_spell 都会跑，漏了 remove 会让 cpu_limit
+	# 5→10→15 地累积，而 hard: 50 会把它封成一个看起来合理的数字，不是显眼的异常值
 	PlayerStats.remove_modifiers_from("core")
 	PlayerStats.add_modifier("cpu_limit", "flat", float(_equipped_core.cpu_limit) if _equipped_core else 0.0, "core")