feat(multisig): multi-sig wallet with proposal-time-snapshotted threshold

[miss-yusrah]

PR description:

feat: Multi-sig wallet with proposal-time-snapshotted threshold

Context

Closes #340.

Adds a new Soroban smart contract (contracts/multisig) implementing a multi-signature wallet where the signing policy (owner list + threshold) is captured at proposal creation time and is immutable for that proposal's lifetime.

Problem solved

Without snapshotting, a live reconfiguration after a proposal is submitted could silently lower the threshold or add a colluding signer — letting a proposal that was created under a strict policy be executed under a weaker one (or vice-versa, deadlocking legitimate proposals).

Design

Concept	Detail
PolicySnapshot	Struct embedded in every Proposal; stores owners + threshold as they were at propose() time
reconfigure()	Admin-only; updates live config but has zero effect on open proposals
approve()	Validates approver against snapshot owners, not current live owners
execute()	Counts approvals against snapshot threshold; uses invoke_contract to dispatch
TTL management	instance storage bumped on every write; persistent proposal entries extended individually

Tests (tests/multisig_test.rs)

• basic_proposal_reaches_threshold – happy path
• reconfigure_does_not_affect_open_proposal – core snapshot isolation: owner removed post-proposal can still approve; newly-added owner cannot
• threshold_snapshot_isolation – raising threshold after proposal creation does not block execution
• non_owner_cannot_propose – access control
• execute_before_threshold_fails – guard
• duplicate_approval_rejected – idempotency guard

All 6 tests pass.

---

Issue #341 — Token-swap with slippage protection

Short commit title:

feat(token-swap): token-swap contract with slippage/front-running protection

PR description:

feat: Token-swap contract with slippage protection against front-running

Context

Closes #341.

Adds a new Soroban smart contract (contracts/token_swap) implementing an on-chain offer/settlement model where the maker's minimum acceptable output (min_output) is enforced at execution time, not at offer creation time.

Problem solved

Without a floor check at settlement, an attacker can front-run the settler by inserting a price-moving transaction ahead of the settle tx in the same ledger close. Because Soroban transactions within a ledger close are ordered deterministically, the exploit is practical. Enforcing output_amount >= min_output at execution time means any settlement that delivers less than the maker's floor simply reverts — the offer stays open and the front-runner gains nothing.

Design

Concept	Detail
create_offer	Maker specifies token_in, amount_in, token_out, min_output; amount_in is immediately escrowed in the contract
settle_offer	Settler provides output_amount; reverts with SlippageExceeded if output_amount < min_output
cancel_offer	Maker can cancel and reclaim escrowed token_in at any time before settlement
Escrow	token_in held by contract; released to settler only on successful settlement
TTL	Instance + persistent storage bumped on every mutating call

Tests (tests/swap_test.rs)

• settle_at_exact_minimum – boundary: exact floor accepted; balances verified
• settle_above_minimum_accepted – price improvement accepted
• settle_below_minimum_rejected – slippage guard fires; offer left open
• double_settle_rejected – idempotency
• cancel_refunds_maker – escrow refund + subsequent settle blocked
• front_run_price_drop_is_blocked – explicit front-running scenario

All 6 tests pass.

[miss-yusrah]

Closing to split into separate PRs per issue (#339, #340, #341).