fix(#695): reject velocity_limit > 0 when velocity_window == 0

[CodedBay]

Summary

When velocity_limit is set to a positive value but velocity_window is zero, dividing by the window to compute per-payer spend rates results in division-by-zero or undefined behaviour at payment time.

This PR adds an early guard in _create_invoice_inner that rejects the invalid configuration before any storage is written, returning ContractError::InvalidAmount via panic_with_error!.

What was changed

contracts/split/src/lib.rs

Added validation in _create_invoice_inner immediately after the existing min_funding_bps guard:

// Issue #695: velocity_limit > 0 paired with velocity_window == 0 would cause
// division-by-zero or undefined behaviour when computing per-payer spend rates.
if velocity_limit > 0 && velocity_window == 0 {
    panic_with_error!(env, ContractError::InvalidAmount);
}

velocity_limit == 0 is always allowed regardless of velocity_window (the feature is simply disabled).

contracts/split/src/test.rs

Two new unit tests:

• test_velocity_limit_without_window_rejected — velocity_limit=1000, velocity_window=0 → panics (#[should_panic])
• test_velocity_limit_with_valid_window_accepted — velocity_limit=1000, velocity_window=3600 → invoice created successfully

Acceptance criteria (from issue)

• create_invoice returns ContractError::InvalidAmount when velocity_limit > 0 and velocity_window == 0
• No error when velocity_limit == 0 regardless of velocity_window
• Unit test verifies rejection for velocity_limit=1000, velocity_window=0
• Unit test verifies acceptance for velocity_limit=1000, velocity_window=3600
• Validation is present before any storage writes

Closes #695

[drips-wave]

@CodedBay Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits