Feat(split): fee waiver system, circuit breaker, compute estimation & payment batching (#922, #923, #924, #925)

[Able-faz-system]

Summary

This PR adds four features to the split contract. Each issue has its own commit. The fee waiver, circuit breaker and compute estimation features
already existed in a basic form; they are extended here, and the existing function names keep working.

#922 Fee waiver system

• New FeeWaiver record for each whitelisted creator: who granted it, when, the expiry (0 = never) and a reason.
• New admin functions (SuperAdmin): grant_fee_waiver and extend_fee_waiver. add_fee_waiver and remove_fee_waiver now also keep the record up to
  date.
• Release now checks creator_has_active_fee_waiver, so an expired waiver no longer removes the platform fee.
• New purge_expired_fee_waivers, callable by anyone. New grants purge expired waivers first, so lapsed entries don't count toward the 100-entry limit.
• Every grant, extension, revocation and expiry purge is written to an audit log (latest 200 entries).
• New read functions: get_fee_waiver, list_fee_waivers and get_fee_waiver_audit_log. New events: fw_exp and fw_purge.

#923 Circuit breaker pattern

• The breaker is now a state machine with three states: Closed (normal), Open (tripped) and HalfOpen (recovering). It stays in sync with the
  existing breaker flag, so all current pause guards still apply.
• Recovery: begin_circuit_recovery moves Open to HalfOpen. complete_circuit_recovery moves HalfOpen to Closed once a configurable waiting
  period has passed. deactivate_circuit_breaker remains as an emergency override.
• Automatic trip: operators report failures with report_circuit_failure. The breaker trips after N failures within a ledger window (default 3 in about
  1 hour), or after a single failure while HalfOpen.
• Exemptions: admins can let chosen operations run while the breaker is open (e.g. refund). require_fn_not_paused enforces this.
• Settings are changed with set_circuit_breaker_config. Every state change is kept in a history log (latest 50) and emits a cb_state event. There
  are also new cb_fail and cb_exmpt events.
• CircuitBreakerStatus now also returns the state, the ledgers when the breaker opened and when recovery started, and the current failure count.

#924 Compute budget estimation

• Each operation has a linear cost model, with built-in defaults for create, pay, release, refund and batch_pay. Admins can override them with
  set_operation_cost_model.
• estimate_operation_cost returns raw and adjusted instruction counts, memory, fee and whether the call fits the budget.
• Operators report measured usage with record_compute_usage. This feeds an adjustment factor that keeps estimates close to measured costs (target:
  within 10%).
• Estimates are cached in temporary storage. The cache is invalidated by a version counter whenever a model changes or new usage is reported.
• Per-operation profiles (sample count, min, max, last, error) are available through get_operation_profile and get_compute_cost_report.
  reset_operation_profile clears a profile.

#925 Payment batching

• New PaymentBatch with a collection flow: open_payment_batch, add_to_payment_batch, remove_from_payment_batch and cancel_payment_batch.
• Items are validated when added and again at execution (status, dispute, deadline, token, remaining balance). Adding the same invoice twice merges the
• Batch size limit: 25 by default, configurable up to 50 with set_payment_batch_limit. Going over the limit panics with BatchLimitExceeded.
• execute_payment_batch is all-or-nothing: one token transfer, then the shared _pool_pay logic credits each invoice. If any item fails, the whole
  call is reverted.
• Each execution returns a BatchExecutionReport with the batched vs. unbatched cost estimate and the savings in basis points (about 36% for 2 invoices
  and 63% for 5 under the default model). get_batching_stats tracks cumulative figures.
• pool_pay now uses the same _pool_pay helper; its behaviour is unchanged.

Other

• Unit tests for each feature in contracts/split/src/test.rs.
• Design notes in docs/ISSUE_922_*.md through docs/ISSUE_925_*.md.

Closes #922
Closes #923
Closes #924
Closes #925

[drips-wave]

@Able-faz-system 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