feat(dex): cap LP providers with deterministic replacement

[andrewnguyen22]

Summary

• cap liquidity pools at 5,000 providers and deterministically replace the lowest-point provider when a better-funded newcomer arrives
• migrate legacy pools of up to 50,000 providers on the first capped deposit while enforcing the 5,000-provider certificate limit for every path, including liveness fallback
• aggregate newcomer deposits by address, use receipt-hash-seeded tie breaking, give evictions distinct deterministic IDs, and expose the auto-withdrawal percentage to indexers
• select and apply replacements in memory and persist the pool once, avoiding thousands of complete 5,000-provider pool rewrites
• permit certificate-result transactions above the individual transaction limit while retaining the collective block/mempool byte bound

Validation

• all non-audit packages: go list -e ./... | rg -v '/audit/' | xargs go test
• go test -race ./fsm -run 'TestHandleBatch|Test.*Capped|Test.*Liquidity|TestHandleDexBatchOrdersEnforcesSettlementCap' -count=1
• go test -race ./lib -run 'TestCertificateResultsMayExceedIndividualMaxTxSize|TestDexBatch' -count=1
• two-node Docker integration: normal cross-chain DEX trade completed successfully
• legacy migration: both 50,000-provider pools converged to the same 5,000-provider state
• maximum newcomer batch on a 1 CPU / 2 GiB node: 1.67s proposal construction and 1.72s validation
• indexing check: 4,999 accepted deposits and 4,999 unique 100% auto-withdrawals, with unique order IDs and no zero-point providers

The repository-wide go test ./... also passes all normal packages; its only failures are checked-in audit/**/artifacts repro directories that are not standalone buildable packages.

[rem1niscence]

Please check the comments left

[rem1niscence]

why do this deletion at the beginning of the function when it will be called again after the withdrawals are processed? shouldn't the second call also clean the "ghost" LPs?

[andrewnguyen22]

Yep, the second pass cleans old ghosts too if we actually reach it. The catch is the early return above: if the batch only touches zero-point holders, totalPointsToRemove is 0 and we never get to that second pass. So the first one clears old ghosts, and the second clears LPs this withdrawal just took to zero.

[rem1niscence]

what's the logic behind using the concrete type? when I first made this change I used the interface in order to avoid the iteration done now to cast to the concrete type as a small optimization, any reason to do this?

[andrewnguyen22]

Yeah, I wanted to keep the interface here too, but encoding/json can't instantiate entries in []lib.TransactionI, so normal tx objects fail to decode on the batch endpoint. Decoding into []*lib.Transaction gives it a concrete target. The loop is only wrapping pointers in the interface slice, not copying the txs, and keeps us from needing a custom decoder or a wider submitTxs change.