fix(tools): reject non-positive and overflow amounts in CampaignTotal…

[cybermax4200]

Problem

CampaignTotals::increment accepted any i128, including negative values and zero. A caller passing a negative amount would silently subtract from the running
total — driving (campaign_id, asset) balances negative with no error. This creates a semantic mismatch with the on-chain storage_increment_total_raised, which
panics on delta <= 0, and corrupts off-chain analytics dashboards that treat these totals as "amount raised".

Overflow was also silent: a sufficiently large amount would wrap, producing a nonsense total.

Changes

• increment now returns Result instead of i128
• Returns Err immediately for amount <= 0, matching the contract's InvalidAmount guard
• Replaces += with checked_add, returning Err on overflow
• Updated all existing tests to .unwrap() the happy path

Tests

Three new cases added alongside the existing six:

Test	Asserts
rejects_negative_amount	increment(..., -100) returns Err containing "positive amount"
rejects_zero_amount	increment(..., 0) returns Err containing "positive amount"
rejects_overflow	adding 1 to a saturated entry returns Err containing "overflow"

All 9 unit tests pass.

Closes #50

[Alqku]

Good defensive check on the increment path — catching negatives and overflow is exactly what we need for #50. Heads up though: flipping 's return type from to is a public API break for downstream callers. Could you either add a non-breaking alongside (leaving 's signature as-is), or handle the validation internally while keeping the current signature? Once that's done this is good to go.