Account commands fail with an opaque VM trap on muxed (M-) addresses #114

Passing an M-address as the account to name or as --owner fails with an opaque VM trap rather than a clear error. Run with a dry run against the testnet unverified registry:

stellar registry account register --network testnet --dry-run \
  --account-name unverified/mux-probe --account-address M...
error: transaction simulation failed: HostError: Error(WasmVm, InvalidAction)
  ... "VM call trapped: UnreachableCodeReached", register_account

--owner M... fails the same way. The CLI passes the strkey through to stellar contract invoke, which encodes it as ScAddress::MuxedAccount. The contract's Address parameters reject that, because Soroban only accepts muxed addresses for MuxedAddress parameters (CAP-67). update-address and preauthorize take the same raw argument, so they presumably hit the same trap.

There's also an inconsistency underneath: the consent check in require_consent resolves the account through resolve_address, which reduces an M-address to its base G-address. So the CLI's own checks look at a different address from the one it sends. A muxed --source-account is fine: it's reduced to its G-address, which is what gets named and owns the name, and that seems correct.

I'd propose catching an M-address in the account and owner positions before invoking, and returning an error that explains names can't carry muxed IDs and suggests the base G-address. The alternative is to strip the ID with a warning and proceed. That would be friendlier, but it registers something other than what the user typed.

Supporting muxed IDs in names properly would be a contract change (MuxedAddress from CAP-67, plus CAP-84 muxed contract addresses on protocol 30) and is being raised as an open question in the named-accounts pre-SEP rather than here.

Feedback wanted: error or strip-with-warning, and whether the owner position should be treated the same as the named address.