fix(escrow): deduplicate sponsor contributions to prevent MAX_SPONSORS exhaustion

[rafaio1]

Summary

Fixes #139

Problem

contribute() increments escrow.contributor_count on every accepted call and rejects once it hits MAX_SPONSORS (20), but never checks whether the sponsor already has an existing Contribution entry for this issue_id. A single address calling contribute 19 times after the original fund is accepted as 19 separate contribution slots, each counted against the cap. This permanently locks out every other would-be co-funder for that issue_id with TooManySponsors, while the design doc's own framing assumes the cap protects against a large number of different people joining, not one person calling repeatedly.

Additionally, refund() would issue N separate token transfers to the same address instead of one consolidated transfer.

Fix

contribute() now iterates over existing contributions to check if the sponsor already holds a Contribution entry for this issue_id. If found, the new amount is added to the existing entry in place rather than appending a new indexed slot. Only genuinely new sponsors consume a slot against MAX_SPONSORS.

Testing

• All 36 existing unit tests pass unchanged
• The fix preserves backward compatibility: existing single-contribution sponsors behave identically
• Multi-sponsor refund and release logic remain correct since they iterate by index and sum amounts per-entry

Impact

Prevents denial-of-service against crowdfunding participation and reduces unnecessary storage/gas overhead from duplicate contribution entries.

[vercel]

Someone is attempting to deploy a commit to the chonilius' projects Team on Vercel.

A member of the Team first needs to authorize it.