feat(soroban-contracts): Add payment splitter contract for revenue sharing (#247)

[amankoli09]

Summary

Implements PaymentSplitter, a Soroban smart contract that distributes
incoming token payments proportionally across multiple recipients using
configurable share weights.

Closes #247

---

Changes

New contract: soroban-contract/contracts/payment_splitter/

File	Purpose
Cargo.toml	Package manifest, links soroban-sdk + upgradeable
src/lib.rs	Contract implementation
src/test.rs	19 unit tests

Modified

• soroban-contract/Cargo.toml — registered payment_splitter as a workspace member

---

Features

• Proportional splits — each recipient holds a u32 share weight; payout is balance × shares / total_shares
• Dust-aware — indivisible remainder (from integer division) always forwarded to the first recipient; contract never accumulates un-claimable dust
• Multi-token — any SEP-41 / Soroban token address works at release time
• Admin-controlled recipient management
  • add_recipient(account, shares) — adds a new payee
  • remove_recipient(account) — O(1) swap-with-last removal
  • update_shares(account, new_shares) — adjust weights without re-initialization
• Reentrancy guard — boolean lock on release() prevents cross-contract re-entry
• Hard cap — MAX_RECIPIENTS = 50 to bound per-call resource usage
• Upgradeable — inherits the project's time-lock upgrade pattern via upgradeable crate
• Rich events — PaymentReleased, RecipientAdded, RecipientRemoved, SharesUpdated

---

Tests (19 / 19 pass)

Category	Tests
Initialization	success, duplicate call, empty list, zero share, duplicate recipient, too many
Release	equal shares, unequal shares (60/30/10), dust to first recipient, nothing to release, single recipient
Recipient management	add, add duplicate, remove, remove nonexistent, update shares, update zero, update nonexistent
End-to-end	add/remove recipients then release

---

Security Notes

• Only the admin may call release(), add_recipient(), remove_recipient(), and update_shares() — prevents griefing
• Reentrancy lock cleared in all early-return error paths
• No floating-point arithmetic — all division is integer; dust handled explicitly

[drips-wave]

@amankoli09 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