fix(circle): reject zero-net payouts in trigger_payout

[fridaypetra55-afk]

Summary

• trigger_payout computed net/fee via math::apply_fee(pool, fee_bps) but never checked whether net came out to zero. If fees consume the whole pool (small contribution_amount + high fee_bps), the function would still transfer 0 tokens, emit a PayoutExecuted event, advance current_round, and possibly mark the circle STATUS_COMPLETED — wasted gas and a misleading audit trail for something that didn't actually pay anyone out.
• Added CircleError::ZeroPayoutAmount and a net <= 0 check right after apply_fee, before any transfers or state mutation occur.
• Added test_trigger_payout_rejects_zero_net_amount, which sets fee_bps to 10000 (100%) so the whole pool is fee, and asserts trigger_payout now fails with ZeroPayoutAmount instead of silently no-op-succeeding.

Note on a pre-existing, unrelated build break

packages/circle/src/contract.rs currently fails to compile on master — confirmed on a clean checkout of upstream/master before any of my changes. 15 functions with Result<(), CircleError> return type end their body with the bare Ok() instead of Ok(()), which doesn't compile (Ok is a 1-argument tuple variant). I fixed all 15 occurrences in this PR since I have to touch this file anyway and couldn't otherwise build or test my change. This appears to have gone unnoticed because the CI workflow (.github/workflows/*.yml) triggers on branches: ["main"], but the repo's default branch is master — so cargo test --workspace has not actually been running in CI.

cargo build -p circle and cargo test -p circle both pass locally after this change (6/6 tests, including the new one).

Closes #117

[drips-wave]

@fridaypetra55-afk 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