Add EventOwedTotal and the over-allocation guard

[0xdevcollins]

The bug this prevents ships green and surfaces as an unpayable winner.

remaining_escrow decrements at claim time, not award time. Under percentages that was safe by construction. With explicit amounts it is not:

$1,000 pool. Award position 1 for $600, unclaimed. A second call awards position 2 for $600. The check sees remaining_escrow still at $1,000 and passes. Winner 1 claims, leaving $400. Winner 2 can never claim.

EventUnclaimedPrizes holds a count, not an amount, so it cannot be reused.

Done when

• DataKey::EventOwedTotal(u64) -> i128 appended (append only, do not reorder variants)
• select_winners enforces sum(new amounts) + owed <= remaining_escrow, reusing InsufficientEscrow
• Test: award, partially claim, award again, verify the second claim still succeeds
• Test: an over-allocating second call is rejected

See plan 3.5.1. Pair-review this one.

---

Plan: boundless-bounty-programs-implementation-plan.md

[coderabbitai]

🔗 Related PRs

#83 - feat(events): replace push-based select_winners with pull-model claim_prize for unlimited winners [open]
#90 - feat(events): pull-model prize claims for Single-release events [merged]
#96 - fix(events): namespace OpSeen by authorizing caller (follow-up to #68/#95) [merged]
#101 - fix(profile,events): replace saturating_add with checked_add + typed errors [merged]
#104 - feat(events): remove per-event participant caps, add paginated list getters [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Bosun-Josh121]

Hello @0xdevcollins,

I am an active open-source contributor and I have a strong background in backend and smart contract engineering (specifically Stellar/Soroban), and I would like to tackle this issue.

This issue aligns perfectly with my skillset. My approach: introduce EventOwedTotal to track the total prize amount owed (as an amount, not a count) and enforce the over-allocation guard at award time in select_winners, so total awarded can never exceed the pool, which is the root cause of the unpayable-winner case in the description. I've reviewed the escrow flow and the remaining_escrow / claim path, so I can implement this without disrupting existing behaviour, and I'll keep it consistent with the follow-ups in #111 and #112.

I can commit to delivering a clean, tested solution within 24 hours, including a test for the exact $1,000 pool with two $600 awards scenario (over-allocation rejected) plus valid-allocation and claim-path coverage. I value clear communication and i'm happy to iterate on any feedback during the review process.