fix: Asymmetric Payout Arithmetic and Consistency Refactor

[Dopezapha]

Closes #307

Description

This PR resolves a critical inconsistency in the payout-automation contract where total_paid calculations were unchecked while pending_amount used saturating arithmetic (#307). This asymmetry previously masked accounting bugs and could lead to silent data corruption or illogical contract states.

Key Changes

• Consistently Checked Arithmetic: All financial state transitions for PublisherEarnings now use checked_add and checked_sub with explicit error handling.

• Improved Diagnostics: Updated the failure messages in execute_payout to correctly identify underflows in pending_earnings, facilitating better troubleshooting of upstream registry errors.

• Entry-Point Hardening: Added non-zero validation and minimum payout enforcement (reading from contract instance storage) to schedule_payout to prevent logic inversions.

• Ledger Counter Safety: Upgraded the payout_id sequence to a checked counter.

[drips-wave]

@Dopezapha 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