Fix/448 flash loan voting

[Seunfunmi-319509]

📌 Description

Provide a clear and concise description of the changes in this PR.

🔗 Related Issues

Use GitHub's auto-close keywords with the # prefix (one issue per line):

Closes #448
Fixes #456
Resolves #789

Multiple issues can be closed by repeating the keyword on separate lines.

🧪 Changes Made

• Bug fix
• New feature
• Refactor
• Documentation update

✅ Checklist

• Code compiles successfully
• Tests added/updated and passing
• Linting passes (no warnings/errors)
• Documentation updated (if required)
• No breaking changes (or clearly documented)

⚠️ Breaking Changes

If this PR introduces breaking changes, describe them here.

📸 Screenshots (if applicable)

Add screenshots to help reviewers understand the changes.

🧩 Additional Notes

Anything else reviewers should know.

[drips-wave]

@Seunfunmi-319509 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

[Seunfunmi-319509]

kindly review

[davidmaronio]

this is the most complete take on the flash-loan voting fix (#448) among the open PRs: cast_vote drops the balance-weight accumulation entirely, verify_with_votes computes approval bps from vote counts in u64 (src/voting.rs:838-842), the weight storage helpers are kept but marked #[expect(dead_code)] for ledger compatibility, and CHANGELOG.md plus EVENT_PAYLOADS.md were updated. the proptest rework to count-based helpers is thorough too.

a few asks:

1. src/voting.rs:813 - the campaign_vote_cast event payload shrinks from (approve, balance, weight) to (approve, balance). that is a breaking change for any indexer decoding a 3-tuple. the docs cover it, but consider keeping a 3-tuple with weight fixed at 1 (like fix: use 1-address-1-vote model to prevent flash-loan voting (#469) #689 does) so existing decoders keep working, or call the break out loudly in the PR description for downstream consumers.

2. src/tests/test_regressions.rs:276 - the [BUG] cast_vote accumulates token weights with unchecked addition — theoretical i128 overflow #354 overflow regression test was deleted outright. fix: use 1-address-1-vote model to prevent flash-loan voting (#469) #689 instead adapts it to assert a vote still succeeds with ApproveWeight near i128::MAX, which preserves the regression coverage; porting that version here would be better than deletion.

3. src/tests/test_voting.rs:616-621 - widening the half-approval tolerance to 3333..=5000 makes the property nearly vacuous. with total >= 2 and integer division, half/total bps is bounded much tighter; something like 4990..=5000 with a minimum total of 1000, or an exact expected value computed in the test, keeps the property meaningful.

4. the deletions of src/clients.rs, src/events.ts, src/types.ts, src/test.rs and the old placeholder rust files duplicate cleanup already on main and should vanish after rebase.

note #689 (issue #469) fixes the same attack with a smaller diff that keeps the weight columns at +1 per vote; maintainers should pick one, and this one is the cleaner end state. this branch is in conflict with main, so please resolve conflicts and rebase, then it is good from my side.