[i5hi]

Boltz-free claim/refund constructors

Expose public constructors that build a claim or refund transaction from a caller-provided lockup UTXO, with no BoltzApiClientV2 in scope — a compile-time guarantee that the unilateral (script-path) spend path can run without any Boltz API call.

Why

new_claim / new_refund fetch the lockup UTXO via fetch_swap_utxo, which is Electrum-first but falls back to the Boltz API when Electrum can't return the UTXO:

• bitcoin.rs: falls back on Electrum error.
• liquid.rs: falls back on Electrum error or an empty (Ok(None)) result — i.e. even when Electrum works but the UTXO isn't found.

For a unilateral rescue of a stuck swap (lockup present, no cooperative claim/refund) we need a path that is provably Boltz-free, using params already on the user's device.

What

• BtcSwapTx::new_claim_with_utxo — made pub (was pub(crate)).
• BtcSwapTx::new_refund_with_utxo — new pub (takes Vec<(OutPoint, TxOut)>, mirroring new_refund's multi-UTXO sweep).
• LBtcSwapTx::new_claim_with_utxo — made pub (was pub(crate)).
• LBtcSwapTx::new_refund_with_utxo — new pub.

The Electrum-only fetch primitives already exist publicly (BtcSwapScript::fetch_utxos, LBtcSwapScript::fetch_utxo), so callers obtain the UTXO with those and construct via the new entries. None of the new/changed functions take a BoltzApiClientV2.

Chain swaps reuse BtcSwapTx / LBtcSwapTx, so all three swap types are covered.

Signing stays unchanged: sign_claim / sign_refund with Cooperative: None already performs the script-path spend with no Boltz access.

Validation

• cargo check --features lnurl,electrum — clean.
• cargo clippy --features lnurl,electrum — no warnings.
• cargo test --features lnurl,electrum --no-run — compiles.
• Behaviour matches the fetch-version constructors minus the UTXO fetch/fallback (same type checks, same empty-UTXO error, same output shape).