fix(asb): serialize Monero locks and refund unfundable swaps

[louislaugier]

Problem

Two swaps running at the same time can both select the same Monero output while building their lock transactions. wallet2 only marks an output spent after its lock transaction is relayed, and monero-sys has no reserve/freeze API, so the second lock becomes a permanent double-spend that monerod rejects, and that swap hangs until the cancel timelock (the recurring "xmr is refundable" reports).

A related case: when concurrent swaps together need more XMR than the maker holds, even a serialized second swap can be forced to reselect the first swap's freshly spent outputs, build a lock that double-spends, and then retry the rejected publish forever (the publish retry has no deadline), wedging until the cancel timelock.

Fix

1. Serialize the construct-to-first-publish window with a process-wide async mutex, so at most one unpublished lock exists at a time. Overlapping swaps that are each fundable then pick different outputs and both succeed. A max-hold deadline releases the mutex if a swap wedges on a rejected publish, so one stuck swap cannot starve the others.
2. Under that guard, before constructing, check the wallet's unlocked balance against what the lock needs. If a concurrent swap already consumed the shared balance, fail with a permanent error that routes to an early Bitcoin refund (no Monero is locked, so this is safe) instead of building a doomed double-spend that wedges the swap.

Testing

concurrent_bobs_before_xmr_lock_proof_sent and concurrent_bobs_after_xmr_lock_proof_sent (both swaps funded, both redeem), a new concurrent_bobs_insufficient_xmr (maker funded for only one of two concurrent swaps; the winner redeems, the loser refunds early rather than wedging), and happy_path all pass locally.

Scope / related

The balance pre-check is best-effort: it is bounded by how promptly wallet2 reflects a sibling's freshly relayed (still unconfirmed) spend. A fully reliable insufficient-funds check under an untrusted daemon needs a daemon-side spent-key-image query, which is what #1142 adds; this change is complementary prevention, not a substitute for that.

• Manage Monero inputs efficiently #120: managing Monero inputs across concurrent swaps.
• Retry locking Monero #138: earlier report of concurrent swaps colliding on the Monero lock.
• feat(asb): rebuild xmr lock tx on confirmed double spend  #1142: the maintainer's rebuild-on-confirmed-double-spend approach (daemon key-image based).
• [RPC] "double_spend" error when using transfer followed by sendrawtransaction monero-project/monero#2585: the wallet2 behaviour (no spent-state update before relay) behind the double-spend.

---

AI disclosure: I used Claude Fable 5 to help investigate and write this change. I understand the code, tested it, and am responsible for it.