fix: cap cool_down_period_s to prevent unstake DoS and add missing event

[Kukrushka]

Summary

Fixes #39.

Set(UpdateCoolDownPeriod) accepted any non-negative i64 value, including i64::MAX. In unstake, the program computes:

let withdrawable_timestamp = current_unix_timestamp
    .checked_add(state.cool_down_period_s)
    .ok_or(ErrorCode::CoolDownOverflow)?;

With a large enough cooldown (e.g. i64::MAX), this addition overflows and every unstake call returns CoolDownOverflow — permanently preventing all users from unstaking their tokens (DoS on withdrawal).

Changes

instructions/set.rs — add upper-bound guard alongside the existing negative-value check:

const MAX_COOL_DOWN_PERIOD_S: i64 = 10 * 365 * 24 * 60 * 60; // ~315_360_000 s (10 years)
if *new_cool_down_period_s < 0 || *new_cool_down_period_s > MAX_COOL_DOWN_PERIOD_S {
    return Err(ErrorCode::InvalidCoolDownPeriod.into());
}

event.rs — add CoolDownPeriodUpdated event so off-chain monitors can detect authority changes to the cooldown without polling state. Previously UpdateCoolDownPeriod was the only admin instruction that emitted no event (inconsistent with UpdateUpdateAuthority).

Test plan

• Verify Set(UpdateCoolDownPeriod { i64::MAX }) now returns InvalidCoolDownPeriod
• Verify Set(UpdateCoolDownPeriod { MAX_COOL_DOWN_PERIOD_S }) succeeds
• Verify Set(UpdateCoolDownPeriod { MAX_COOL_DOWN_PERIOD_S + 1 }) returns InvalidCoolDownPeriod
• Verify CoolDownPeriodUpdated event is emitted on successful update

🤖 Generated with Claude Code