Implement payer refund priority queue under partial liquidity

[Kingsman-99]

Label: complexity: high
Points: 200

Description

refund() assumes the contract always holds enough token balance to refund everyone in full. In an edge case where custody is short (e.g. interaction with the streaming/DEX-swap features leaves less than expected), there's no defined, fair order for partial refunds. This issue adds an explicit priority rule.

Technical Context

Involves lib.rs refund() — before transferring, check token_client.balance(&env.current_contract_address()) against the sum owed; if short, refund payers in ascending order of contribution amount first (protects smaller contributors fully before larger ones absorb any shortfall), rather than reverting the entire refund.

Acceptance Criteria

• When contract balance is fully sufficient, behavior is unchanged from today
• When balance is insufficient, smallest contributors are refunded in full first, in ascending order, until balance runs out
• The last payer(s) who can't be fully refunded receive a partial amount (not zero, not a panic) up to whatever remains
• Emits a new refund_shortfall event recording the total shortfall amount when this path triggers
• Test simulates an artificially reduced contract balance and verifies ascending-order partial refund distribution
• All existing cargo tests pass
• cargo clippy passes with zero warnings

---