fix(#445): replace unchecked i128/u32 additions with checked_add to prevent overflow

[dedukpe]

Summary

Closes #445

In src/contributions.rs and src/revenue.rs, several unchecked i128 and u32 additions could silently overflow on high-balance tokens (e.g., 18-decimal tokens with large supplies). This PR replaces all of them with checked_add(...).ok_or(Error::Overflow)? to ensure safe overflow handling.

Note: verify_with_votes in src/voting.rs already uses checked_add for total_votes and total_weight (fixed in prior work). This PR extends the same pattern to the remaining locations.

Changes

src/contributions.rs (46 lines changed)

• check_contribution_caps: cap comparison now uses checked_add
• update_contribution_accounting: return type changed from () to Result<(), Error>; 5 additions (amount_raised, effective_amount_raised, contribution, lifetime, total_raised) all use checked arithmetic
• contribute(): personal cap check uses checked_add
• batch_contribute(): personal cap check uses checked_add

src/revenue.rs (31 lines changed)

• deposit_revenue: pool accumulation uses checked_add
• claim_revenue: claimed amount and distributed accumulator use checked_add
• claim_creator_revenue: claimed amount uses checked_add

Security Considerations

• Follows the same pattern already used in cast_vote for consistency
• CEI (Checks-Effects-Interactions) pattern preserved — state updates happen before external token transfers
• Error::Overflow variant (discriminant 30) already exists in src/errors.rs

Testing

• All existing tests should continue to pass
• Overflow behavior is deterministic: large values return Error::Overflow instead of silently wrapping

[drips-wave]

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

[davidmaronio]

good sweep for #445. converting the raw + additions in check_contribution_caps, update_contribution_accounting, the personal-cap checks and the revenue pool/claim paths to checked_add(...).ok_or(Error::Overflow)? is the right pattern, and threading Result through update_contribution_accounting is done cleanly.

blockers:

1. src/revenue.rs:130 - the set_revenue_claimed(...) call ends with ) and no semicolon, right before the comment block and the next statement. that is a syntax error and is why fmt, clippy and test are all red. add the ;.

2. src/revenue.rs:144 - claimants_so_far + 1 is still an unchecked add while everything around it got converted. it is a claimant counter so overflow is unrealistic, but for consistency with the PR's stated goal make it checked_add(1).ok_or(Error::Overflow)? too (same for any remaining + 1 counters you touched around).

3. after fixing, run cargo fmt and cargo clippy --features testutils locally; the branch is also behind main, and part of the red CI likely comes from the stale base.

please fix the semicolon, rebase on main, and get CI green; the substance is otherwise ready.

[davidmaronio]

all three items addressed: the set_revenue_claimed call is fixed, both claimants_so_far + 1 counters now use checked_add, and fmt/clippy/test are green on a fresh base. consistent overflow handling across the contribution and revenue paths, good work.