Feat: security audit framework, partial payment tracking, velocity limits & split rules engine (#892, #911, #912, #913)

[Barbie-Dev]

Summary

Implements four features in the split contract. Each one lives in its own module with events, contract entry points and tests, and each issue is a
separate commit.

#892: Contract security audit framework (security_audit.rs)

• Admin-managed auditor registry (add_security_auditor, remove_security_auditor, get_security_auditors)
• Contract-level audit checks: admin set, admin roles present, treasury set, platform fee ≤ 100%, circuit breaker off, contract not paused
• Invoice-level audit checks: recipients match amounts, amounts are positive, no duplicate recipients, no overflow in the total, funding within the
  total, split-rule and ratio lengths are consistent
• Saved audit reports with pass/fail counts, number of critical failures and a severity-weighted risk score (run_security_audit,
  run_invoice_security_audit, get_security_audit, get_security_audit_count)
• Security event log capped at 100 entries (log_security_event, get_security_events)
• Events: sec_adtr, sec_aud, sec_evt

#911: Partial invoice payment tracking (payment_tracking.rs)

• Per-recipient tracking of amount due and amount paid (PaymentTracker, RecipientPaymentState)
• Milestone state machine: Pending → Reached → Settled; milestones are reached automatically and settled strictly in order
• Per-recipient paid flags stored as a u64 bitmask (get_recipient_paid_flags, is_recipient_paid)
• Atomic updates: all checks run before anything is written, so a failed call leaves storage unchanged
• Entry points: init_payment_tracking, record_partial_payment, settle_payment_milestone, get_payment_tracker
• Events: pt_init, pt_pay, pt_mile

#912: Payment velocity limits (velocity.rs)

• VelocityConfig: max payments per window, max amount per window, window length, cooldown between payments
• VelocityState stored per payer; resets when the window elapses
• Admin sets default limits and can override them per payer (set_velocity_config, set_payer_velocity_override)
• Enforced in the main payment path (_pay); does nothing unless limits are configured, so existing behaviour is unchanged
• Handles edge cases: zero or negative amounts, overflow, invalid configs (a window limit with no window, a negative cap)
• Read/admin helpers: get_payer_velocity_config, get_payer_velocity_state, check_payer_velocity, reset_payer_velocity
• Event: vel_cfg

#913: Split rules engine (split_rules.rs)

• SplitRuleDef: target recipient, priority, condition, amount
• Conditions (RuleCriteria): Always, FundedAtLeast, FundedBelow, PayerCountAtLeast, AfterTimestamp, BeforeTimestamp
• Amounts (RuleAmount): Fixed, Percentage (bps), Remainder
• Evaluation: for each recipient, the matching rule with the lowest priority value wins; Remainder gets what is left; fails if the total would exceed
  the funded amount
• Validation: recipient index in range, no duplicate priorities for the same recipient, positive fixed amounts, percentages between 1 and 10000 bps,
  non-negative thresholds, at most one remainder recipient, unconditional percentages ≤ 100%
• Rules stored per invoice: set_invoice_split_rules, clear_invoice_split_rules, get_invoice_split_rules, evaluate_invoice_split_rules,
• Event: srules

Tests

Unit and integration tests for every feature were added to contracts/split/src/test.rs (test_892_*, test_911_*, test_912_*, test_913_*).

Closes #892
Closes #911
Closes #912
Closes #913

[drips-wave]

@Barbie-Dev 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