Function: AddToWard(amount)
Description: Adds to the current spell's ward on its primary target, capped at the ward's original BaseDamage without unsigned overflow. The ward must belong to the exact current spell instance; an old callback cannot replenish a replacement ward with the same spell ID. Requires an active, non-resisted spell with caster and zone. An existing ward sends absorb-regeneration notifications for current targets and refreshes a player caster's maintained display.
Parameters:
amount: unsigned amount to add to the existing ward budget.
Returns: None. A missing primary target or matching ward has no effect.
Connection lifetime: Each player or group-member connection resolved by this function is retained through the native call. A disconnect or reconnect during a callback cannot destroy that retained connection or switch the ongoing call to a replacement. A later Lua call resolves the current connection. This does not extend the lifetime of unrelated spawn or item userdata.
Spell caster lifetime: When this function reads a spell's caster, it retains that allocation for the native operation. Retirement or callback reentry cannot replace its caster with a different allocation at the same address or runtime ID. A known expired or cleared caster is not rediscovered through a replacement connection. An actor already owned by the active callback remains usable through that callback. See Lua actor lifetime.
Ward and target lifetime: Target lookup acquires the actor under zone publication before checking its type or using it. Ward records have one owner; reads return value snapshots and mutations occur under the ward lock. A ward remembers its spell through a weak allocation control. Damage processing and notifications retain the acquired spell and actor owners, and notifications run after the ward lock is released so callbacks can remove or replace wards. See Lua actor lifetime.
Original spell targets: When this function uses a spell's target list, it snapshots references to the originally selected actor allocations. It skips unavailable or departed targets instead of selecting another actor with a reused runtime ID. Accepted actors remain physically retained through the active protected callback, including Lua errors; saved userdata and target records do not keep them alive between callbacks. Explicit Spawn arguments retain their existing selection behavior. See Lua actor lifetime.