Guarded and smart multisig accounts pay no transaction fee

[WiktorStarczewski]

AuthGuardedMultisig and AuthMultisigSmart resolve the fee conversion info from the auth args and then discard it, so accounts using them pay no transaction fee on a fee-charging chain.

Both components contain, verbatim:

exec.multisig::resolve_auth_args
# => [CONVERSION_INFO, block_number, SALT]

# this component does not pay the transaction fee yet, so the conversion info is unused
dropw

Expected: they pay the fee, as the other auth components do.

Impact: guarded and smart multisig accounts transact for free while singlesig and plain multisig accounts pay. It fails open, not loudly — the fee moved out of the kernel epilogue into the auth procedure, and neither the batch nor the block kernel validates that a transaction paid one (grep -ri fee crates/miden-tx-batch/src crates/miden-block-prover/src → no matches). So there is no error anywhere; the fee note is simply never created.

Four of six auth components pay:

component	exec.fee::pay_fee
singlesig	1
multisig	1
no_auth	1
network_account	1
guarded_multisig	0
multisig_smart	0

Repro: execute any transaction from a guarded- or smart-multisig account on a chain with a non-zero verification_base_fee. The transaction succeeds and produces no TX_FEE output note. On MockChain::builder().verification_base_fee(500), executed_transaction.output_notes().num_notes() is 0 where the equivalent plain-multisig transaction yields 1.

Origin

The comment was introduced in #3731, which built multisig::resolve_auth_args and moved the fee-paying multisig component off fee::load_conversion_info. The plumbing is in place and the payment step was deferred — the conversion info is already decoded and correct at the point where it is dropped.

Fix: mirror asm/components/auth/multisig/multisig.masm — feed the resolved conversion info and a cycle estimate into fee::pay_fee before the summary is created, so the fee note and the vault withdrawal funding it are covered by the signatures. For the guarded component the estimate needs one extra signer, since the guardian signature is verified in addition to the approvers'.

Note this changes both components' procedure roots, and therefore the code commitment of every account using them.

[partylikeits1983]

I think we should avoid using caller-provided CONVERSION_INFO under reduced quorum multisig policies, such as guardian rotation.

fee::pay_fee should still run before the transaction summary is created, so the fee note and vault withdrawal are covered by the signatures. But for guarded/smart multisig, custom conversion info lets the tx executor host to choose the fee asset and conversion rate, so it should require the default multisig threshold.

For guardian rotation, we should either force native 1:1 fee payment or require the normal guardian path. This fixes the missing fee issue without allowing reduced threshold procedures to withdraw arbitrary fee amounts from the account vault.