fix(order_handler,referral_storage): pool_amount drift, execution_fee double-refund/absorption, zero-threshold tier gate (#629-631, #636)

[prodbycorne]

Summary

• order_handler::liquidate_position pays the keeper's liquidation_execution_fee via withdraw_from_pool without decrementing pool_amount, permanently drifting the pool ledger above real balance #629 (critical): liquidate_position paid the keeper's liquidation_execution_fee via market_token::withdraw_from_pool — a raw token transfer with no knowledge of data_store's pool_amount ledger. Every other real pool withdrawal in this codebase pairs the transfer with a matching apply_delta_to_pool_amount; this one didn't, permanently drifting pool_amount above the pool's real balance on every liquidation with a nonzero fee configured. Added the missing delta call.
• order_handler::cancel_order double-refunds execution_fee — collateral_delta_amount already includes it, per the repo's own #258 regression test #630/closed #390 still live: execute_order never pays execution_fee to the keeper — worse, the fee is silently absorbed into position collateral / swap input instead of being stranded #631 (critical, shared root cause): create_order/create_orders stored the entire record_transfer_in snapshot as collateral_delta_amount — which already includes execution_fee, since the router pushes both in one combined deposit. This meant cancel_order double-refunded the fee (reverting the cancellation, or paying it out of other users' funds), and execute_order never paid the fee to the keeper at all — instead silently folding it into position collateral or swap input. Fixed at the source: collateral_delta_amount = received - execution_fee (rejecting an underfunded order), and execute_order now pays order.execution_fee to the keeper on every successful dispatch, mirroring cancel_order/cleanup_expired_order's existing handling of the same field.
• referral_storage::set_tier_upgrade_threshold accepts 0, instantly qualifying every referrer for that tier #636: referral_storage::set_tier_upgrade_threshold validated tier but never threshold_usd — a 0 threshold instantly qualifies every referrer for that tier at their first trade, since cumulative_volume >= 0 is always true. Rejects threshold_usd == 0 with the existing InvalidInput error.

Test plan

• cargo build -p order-handler -p referral-storage — compiles clean
• cargo test -p order-handler — 53 passed, 3 failed (all three pre-existing and unrelated — an oracle stale-price panic in keeper-heartbeat tests, already confirmed unrelated on a clean upstream/main checkout in fix: position TTL renewal, shared TTL-bump constants, keeper/router doc fixes (#657-660) #675)
• cancel_order_refunds_execution_fee_to_user — the repo's own existing regression test written for the order_handler::cancel_order double-refunds execution_fee — collateral_delta_amount already includes it, per the repo's own #258 regression test #630 bug — now passes (was failing before this fix)
• Added liquidate_position_keeper_fee_decrements_pool_amount (order_handler::liquidate_position pays the keeper's liquidation_execution_fee via withdraw_from_pool without decrementing pool_amount, permanently drifting the pool ledger above real balance #629): asserts pool_amount drops by exactly the keeper fee
• Added set_tier_upgrade_threshold_rejects_zero (referral_storage::set_tier_upgrade_threshold accepts 0, instantly qualifying every referrer for that tier #636)
• cargo test -p referral-storage — all passing

Closes #629
Closes #630
Closes #631
Closes #636

[drips-wave]

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