Support muxed (M…) source accounts in the contract invoke pipeline

[fnando]

Background

Spun out of review feedback on #2644 (stellar token transfer). SEP-41 supports muxed addresses (CAP-67 ScAddress::MuxedAccount), and --from M… almost works today: UnresolvedMuxedAccount resolves it, and arg parsing + simulation accept it.

Problem

It then fails in the shared contract invoke pipeline at cmd/soroban-cli/src/commands/contract/invoke.rs:349:

client.get_account(&config.source_account()?.to_string()).await?

The M… strkey is handed to a G-only ed25519 parser, aborting with a raw strkey DecodeError. Because this lives in the shared pipeline, contract invoke --source-account M… hits the same failure — it is not specific to token transfer.

Direction

stellar-xdr already provides xdr::MuxedAccount::account_id(). The pipeline should use the underlying AccountId (e.g. config.source_account()?.account_id().to_string()) for the sequence-number lookup and the classic transaction source in build_invoke_contract_tx, while the muxed form keeps flowing into the SEP-41 transfer(from, …) argument so the mux id is preserved on-chain / in events.

Acceptance

• --source-account M… / --from M… works end-to-end through simulate → sign → submit.
• Add an integration test with an M… source (signing via an identity / --sign-with-*, since an M-literal carries no secret).

Notes

Pre-existing limitation, not a regression from #2644. Until this lands, token transfer may want a clear "muxed source not yet supported" guard error instead of the raw DecodeError.

Part of the "Improve Agent UX for Wallets" epic (#2620).