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/spell_system/spell_evaluator.gd

@@ -329,12 +329,8 @@ func execute_compiled(compiled: CompiledDeck, caster_id: int, spawn_pos: Vector2
 	var heat_mult: float = 1.0 + PlayerStats.mana_heat
 	var deck: SpellDeck   = compiled.make_runtime_deck()
 	var ops_count:         int = 0
-	# 生效 cpu_limit 已含法杖份额（combat_manager 以 source="core" 的加成接入）
-	# 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)
+	# 生效 cpu_limit 已含法杖份额（combat_manager._rebuild_wand 以 source="core" 的加成接入）
+	# 下限 1：注入缺失时不把游戏打成砖（0 会让 while 一步都不走）；该异常由 equip_wand 处报出
 	var max_ops:           int = MAX_OPS_PER_CPU * maxi(PlayerStats.cpu_limit, 1)
 	var actions_remaining: int = 1  # 初始为 1，由 multicast_count 加成
 	while deck.has_next() and ops_count < max_ops: