feat(network-monitor): add fees support

[SantiagoPittella]

Closes #2450

Summary

On fee-charging chains the monitor now funds its accounts from the faucet (reusing the existing PoW token-request flow) and keeps itself funded:

• Wallet and counter are funded with public P2ID faucet notes, consumed as unauthenticated input notes by each account's first transaction (input-note assets land before the epilogue withdraws the fee, so empty-vault accounts bootstrap themselves).
• The counter prices the increment note at the per-transaction fee bound, so every increment attaches a FEE_SPONSORSHIP note that pays for the network transaction consuming it. It also allowlists the sponsorship and P2ID scripts and carries BasicWallet (as does the wallet, to consume P2ID notes).
• The wallet's fee balance is tracked, shown on the dashboard, and topped up automatically from the faucet when it runs low. A failed top-up flips the card unhealthy.
• The fee asset is callback-enabled, so every transaction moving it must provision the issuing faucet as a foreign account. The monitor fetches the faucet's full state and witness at the reference block.
• The remote-prover probe funds its payload the same way, but does not require re-funding since it never actually spends it. A fee-charging chain without --faucet-url fails the monitor at startup

Mainnet, which has no faucet, is a follow-up.

Also in this PR:

• Genesis now pre-funds the native faucet's own vault with 1,000 MIDEN. Mint requests execute as network transactions paying fees from the faucet's vault, which was empty, so minting deadlocked on any fee-charging chain.
• Bumped the miden protocol dependencies from 0.16.0-rc.4 to 0.16.0-rc.6 (version pins only, no code changes needed).
• Zero-fee chains keep today's exact behavior.

TEsted it against a live local stack (fee-enabled genesis, base fee 500) with the faucet from 0xMiden/faucet#289: funding, deployment, increments with sponsorships, and automatic top-up all worked end to end.

Changelog

[[entry]]
scope       = "network-monitor"
impact      = "added"
description = "Support fee-charging chains: the monitor funds its accounts from the faucet, attaches fee sponsorships to increment notes, and tops its balance up automatically."

[[entry]]
scope       = "node"
impact      = "fixed"
description = "Pre-fund the generated native faucet's own vault at genesis so its mint network transactions can pay fees."

[[entry]]
scope       = "general"
impact      = "changed"
description = "Bump miden protocol dependencies to 0.16.0-rc.6."

[igamigo]

Genesis now pre-funds the native faucet's own vault with 1,000 MIDEN. Mint requests execute as network transactions paying fees from the faucet's vault, which was empty, so minting deadlocked on any fee-charging chain.

I think this should not be needed - instead, the sponsorship note should pay for the network transactions. These notes are created by operator account which should have tokens already. Two things to keep in mind here:

• Mint and burn notes are both (expectedly) priced at 0 (link). By default a client will not pay for such notes because they would be free, but for the native faucet we want to do it anyway as it needs to pay for the transaction itself. I think this is what may have prompted you to add this workaround
• However, another actual blocker which we have to fix separately is that we were setting an incorrect fee asset ID for the native faucet (link, we call out in the TODO the protocol issue/PR we needed; this is what we need to address). This would ideally not be a problem because the actual fees are 0, but the NTX builder will not pick up these notes and even if it did, the executor would error out because the asset ID did not match the expected one.
  • I think the referenced protocol PR here has not actually landed on any RC release, so it'd need to be done or we would have to basically duplicate the code on the node.

cc @Mirko-von-Leipzig @mmagician

[mmagician]

Mint and burn notes are both (expectedly) priced at 0 (link).

This works now, but it will need to change at the point when batch builders' tx acceptance criteria change and they require fee payment.

I think the referenced protocol PR here has not actually landed on any RC release, so it'd need to be don

Thanks, good catch! I created a v0.16.0-rc-7 release now, I think that PR just missed the rc-6 release earlier.

[igamigo]

Mint and burn notes are both (expectedly) priced at 0 (link).

This works now, but it will need to change at the point when batch builders' tx acceptance criteria change and they require fee payment.

Even though the notes are currently priced at 0 and the batch builders will accept transactions with 0 fees, the current situation is that pay_fees does happen unconditionally, which means we either:

• Have assets in the faucet's vault. I don't think we want that based on some previous discussions, but not 100% sure. This is what this PR resorted to. Eventually the network account would run out of faucets in this scenario
• Price notes at 0 and from the operator, still send sponsorship notes that have enough assets to cover the transaction. We'd rely on the NTX builder still trying to pair the network note with it (which I think it does)

[SantiagoPittella]

I moved the deps bump and genesis changes to #2538 , which will be ready to merge after the fix of the protocol releases.