Emit per-recipient payout legs so payout history can be reconstructed

[grantfox-oss]

Problem

The contract emits only aggregate events. SplitPaid, Deposited, and Distributed all carry { id, token, amount }: the total that went through the split. payout() computes the per-recipient breakdown via amounts() and then throws it away.

Nothing on-chain records who received what.

Why this matters

You cannot recompute the breakdown after the fact, because update_split() can change recipients and shares at any time. An indexer replaying a SplitPaid from ledger 100 has no way to know the share table as it existed at ledger 100: reading get_split today returns the current table. So historical payouts are permanently unreconstructible from chain data.

This directly blocks:

• Show payout history inside the split detail view #63 (Show payout history inside the split detail view). Any history built today would either omit per-recipient amounts or compute them from the current shares, which is silently wrong for any split that was ever updated.
• The indexer's value proposition generally. export-csv.mjs has an amount column but can never populate a per-recipient one.

Suggested fix

Emit a per-recipient leg alongside the aggregate. Either a PayoutLeg { id, token, recipient, amount } event per recipient inside payout(), or extend the existing events with a vector of legs.

Trade-off to weigh in the PR: a leg per recipient means up to MAX_RECIPIENTS (32) extra events per payment, which costs resources. Emitting one event carrying a vector is cheaper but harder to filter on by topic. Benchmark against #53 (worst-case 32-recipient payout cost).

Acceptance criteria

• A payment through a split emits enough data to attribute an exact amount to each recipient, without reading current contract state.
• Nested Recipient::Split legs are distinguishable from Recipient::Account legs.
• Tests assert legs sum to the payment total (ties into the conservation property in Property-based tests for share conservation #52).
• The event schema change is documented in the event model docs, and the resource cost is measured.
• Show payout history inside the split detail view #63 can be implemented against these events.

[Tobi-8]

Hey maintainer, I have experience in handling this issue
Kindly assign

[Afolabi08]

I'd like to take this on. I've worked on Soroban/Rust contracts before, including event schema design and resource cost tradeoffs. I can implement per-recipient PayoutLeg events, benchmark the per-leg vs vector-event approach against the worst-case 32-recipient cost, add tests asserting legs sum to the payment total, and document the event schema change.

[grantfox-oss]

🦊 GrantFox — @Afolabi08 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #258)
2. Your PR will be reviewed by the tributary-protocol maintainers

Good luck! Track your progress on GrantFox.