integration_test.rs Step 20 (split) picks an invalid holding when pending-withdraw exists

[gyorgybalazsi]

Follow-up from #46 / v0.4.2 verification.

Context

examples/integration_test.rs Step 20 ("Split sender holding", introduced in #41) picks holdings.first() and asks the registry to split it. In the current test flow Step 17 (Submit withdrawal) precedes Step 20, leaving one of the two remaining UTXOs locked by a pending bitcoin withdrawal. The transfer factory rejects the split request with:

Transfer factory request failed [400 Bad Request]: {"error":"Given holdings are invalid"}

This blocked end-to-end verification of split.rs's parser during PR #46's hotfix run. The parser fix was verified by fixture tests (in #46) and by 4 other end-to-end steps, but the split path was not exercised against devnet.

Repro

cargo run --example integration_test

…fails at Step 20 with the error above, after Steps 1–18 pass and 19 skips.

Proposal

Filter holdings to exclude holdings that are tied up in pending withdrawals (or, more simply, pick the holding with the largest amount — heuristically the freely-transferable one in this scenario). The Holding struct in src/mint_redeem/models.rs:329 doesn't carry a "locked" flag today, so the safe heuristic is largest-amount.

Alternative: reorder the test so the Split step runs before the withdrawal step, when all holdings are free. Slightly more invasive (changes step numbering and the // Step N: comments) but eliminates the "which holding is free?" guesswork.

Affected files

• examples/integration_test.rs Step 20 block (around line 807).

Out of scope

Anything in src/split.rs. The library code's behavior is correct; only the test step's input selection is broken.