fix(finalizer): protect pending swap orders' source balance from Binance finalizer withdrawals

[droplet-rl]

Problem

The Binance finalizer deducts pending rebalance orders' destination-token amounts (getPendingRebalances) from the shared exchange account's withdrawable balance, but nothing protects the source-token side of an order in PENDING_DEPOSIT. When a swap order's deposit is credited while the finalizer has withdrawal backlog in the same coin, the finalizer withdraws the just-credited funds to service that backlog. The order then fails its balance check every cycle ("Available balance for input token ... is less than amount to transfer"), never places its spot order, and starves until REBALANCER_PENDING_ORDER_TTL (default 1h) elapses and BaseAdapter._redisCleanupPendingOrders prunes it.

Observed 7 times over 2026-07-01 → 2026-07-08 on USDT→USDC (HyperEVM) swap-rebalancer orders. Fully traced example (2026-07-08, cloid 0xe42d273cb1ce29c53aad23e9241606cd):

• 04:56:09 — 82,385.72 USDT-BNB transferred to the Binance deposit address (tx), order created in pending-deposit
• ~04:58 — Binance credits the deposit
• 04:59:27 — finalizer withdraws exactly 82,385.724629 USDT back to BSC against a pre-existing 158k amountToFinalize backlog (pendingRebalanceDeduction was 0 for USDT — only the destination-side USDC was protected)
• 05:56:12 — order pruned without finalization

Change

• Add RebalancerAdapter.getPendingDepositSourceAmounts(account) — source-token amounts of orders in PENDING_DEPOSIT, keyed by source chain/token — implemented generically in BaseAdapter from the existing Redis status set (all adapters extend BaseAdapter).
• getPendingBinanceRebalanceDeductions now also deducts these source-token amounts. The source- and destination-side maps are netted to positive per-coin amounts independently before being summed, so negative on-chain adjustments in getPendingRebalances (e.g. intermediate bridge legs) cannot cancel the source-side protection.
• Docs: updated the Binance Finalizer section of src/rebalancer/README.md.

The deduction is deliberately conservative: for same-coin (no-swap) routes the order is briefly protected on both source and destination sides while in PENDING_DEPOSIT; over-deduction only delays finalizer sweeps, which self-resolves when the order progresses or is pruned.

Not in scope (follow-up)

The prune events also revealed a second issue: the 30-minute SWAP deposit tag expires while the finalizer's deposit-history lookback is much longer, so every swap deposit — including successfully swapped ones — is later re-counted into the finalizer's amountToFinalize ledger (this is where the 158k/248k backlog that consumed the traced order's deposit came from). That accounting fix is intentionally left to a separate PR.

Testing

• yarn tsc --noEmit clean
• hardhat test test/BinanceFinalizer.ts — 9 passing (2 new)
• hardhat test test/RebalancerClient.cumulativeRebalancing.ts — 19 passing
• eslint + prettier clean on touched files

🤖 Generated with Claude Code

[droplet-rl]

Closing in favor of #3560 per discussion in Slack: rather than deducting pending orders' source-token amounts from the finalizer's withdrawable balance (treating the symptom), #3560 stops the phantom amountToFinalize debt from forming in the first place by tying the SWAP deposit tag's lifecycle to order state — persistent while the order lives or after it consumes the deposit, deleted on TTL prune so the finalizer can reclaim abandoned funds.