Soroban Contract Security Flaw: Unbounded Instance Storage Growth in `distribute_winnings()` Exhausts TTL Budget

A critical security and performance flaw has been identified in a Soroban smart contract's payout function. The `distribute_winnings()` method stores each payout record directly in the contract's **instance storage**, a design choice that leads to unbounded growth and threatens the contract's long-term viability. Instance storage is intended for a small, fixed set of keys that persist for the contract's lifetime, with a single shared Time-To-Live (TTL) budget. By creating a new storage key for every payout—using a combination of `idempotency_key` and `winner`—the contract's storage footprint expands indefinitely with each transaction.

This architectural error creates two immediate, concrete risks. First, the **TTL cost** escalates uncontrollably. Every read or write operation to instance storage triggers an extension of the TTL for the entire instance dataset. As the number of stored payout records grows, the rent cost required per transaction increases proportionally, imposing a direct and rising financial burden on contract operations. Second, the contract faces a hard **storage limit exhaustion**. Instance storage has a finite capacity; an unbounded accumulation of records will eventually hit this ceiling, at which point the `distribute_winnings()` function—and any other function relying on instance storage writes—will fail, potentially freezing critical payout operations.

The flaw represents a fundamental mismatch between the contract's data persistence strategy and Soroban's storage model. It signals a significant oversight in contract design where transient or frequently generated data is incorrectly placed in long-term, costly storage. For any project relying on this contract, the unbounded cost growth and eventual functional failure are not theoretical risks but inevitable outcomes unless the data structure is migrated to the more appropriate and scalable temporary or persistent storage tiers. This exposes the deploying entity to escalating operational costs and the risk of a complete service halt.