fix(atomic-swap): allow permissionless release with preimage

[mimi-esc]

Summary

• remove the counterparty signature requirement from AtomicSwapHTLC release
• preserve the fixed payout destination at swap.counterparty
• add coverage proving a third-party caller can release and receives nothing
• document that refund remains permissionless and safely pays only the initiator

This matches the delegated-release HTLC approach from Micopay Protocol PR #327: the valid preimage authorizes release, while the stored counterparty controls the destination.

Verification

• git diff --check passed
• cargo test --workspace not run: Cargo is unavailable in the environment

Closes #36

[ericmt-98]

Thanks @mimi-esc — this is the version of BRIDGE-15 I want to take. The contract change is right: the preimage is the authorization, the payout destination stays pinned to swap.counterparty, and refund was already permissionless with a fixed destination, so the two paths are now symmetric. The doc comments on lock/release/refund are a genuine improvement.

One blocker before merge, and it's in the test rather than the contract.

TestEnv::new() calls env.mock_all_auths() (contracts/atomic-swap/src/test.rs:25), which auto-approves every require_auth(). That means test_third_party_release_pays_only_counterparty passes just as happily against the current main, with swap.counterparty.require_auth() still in place — so it doesn't demonstrate the behaviour the issue is about. env.as_contract(&t.third_party, ...) doesn't help either: it sets the invoking-contract context, not the authorization set, and third_party is a plain address rather than a registered contract.

What would actually pin the fix:

// authorize only the initiator's lock, then release with nothing authorized
t.env.set_auths(&[]);
t.client().release(&swap_id, &secret);

i.e. build the swap under mocked auths, then clear them (set_auths(&[]) / a scoped mock_auths) before calling release. That test fails on main and passes on this branch — which is the property worth locking in. Keeping the balance assertions you already have (counterparty credited, caller gets nothing, contract drained to zero) on top of that would be ideal.

Worth noting the same gap existed in #36, which I've closed in favour of this PR.