Recipient Share Precision Rounding Policy

[Kingsman-99]

Description

When splitting an integer token amount across many recipients with non-divisible ratios, rounding discrepancies cause the sum of individual shares to differ from the invoice total by up to N-1 stroops. A defined rounding policy must ensure every stroop is accounted for.

Technical Context

Implement a distribute_with_remainder(total: i128, ratios: &[u32], denom: u64) -> Vec<i128> function in a new calc.rs module under contracts/split/src/. Apply the largest-remainder method: compute floor shares, compute remainders as (total * ratio % denom), sort recipients by remainder descending, and distribute leftover stroops to top-remainder recipients.

Acceptance Criteria

• Sum of all distributed shares always equals total exactly
• Recipients with larger fractional remainders receive the extra stroop
• Function is pure (no side effects, no storage) and fully unit-tested in calc.rs
• A property-based test asserts sum(distribute_with_remainder(...)) == total for random inputs
• Existing release_payment uses distribute_with_remainder for its calculations
• All CI checks (cargo build --target wasm32-unknown-unknown, cargo test, cargo clippy) pass and the branch has no merge conflicts

---

[DavisVT]

@DavisVT has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

i'm a developer well fit for implementing this task
Kindly assign them to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @DavisVT to this issue.