Nothing enforces that a network account's active fee policy prices the config-note root

## Summary

`AuthNetworkAccount::new` force-allowlists `NetworkAccountConfigNote::script_root()` on every network account, and fee collection prices every input note it consumes. So an account whose *active* fee policy has no schedule entry for that root cannot consume the one note that reconfigures it. Nothing enforces the pairing.

## Where it can break

- `AuthNetworkAccount::new`, `NetworkAccount::builder`, `create_network_fungible_faucet` and `create_network_non_fungible_faucet` all accept a caller-supplied `FeePolicyManager` and validate nothing.
- Onchain, `set_fee_policy` is the sharper one. `remove_allowed_fee_policy` carefully refuses to remove the *active* policy root (`ERR_FEE_POLICY_ROOT_IS_ACTIVE`), but nothing stops an authorized operator from *activating* a registered policy that has no entry for the config-note root. That permanently freezes the allowlists on any account.

## Options

- Rust side: validate in `AuthNetworkAccount::new` when the active policy root is `BasicConstantFeePolicy::root()`. `FeePolicyManager` retains the policy components, so the fee-schedule map slot can be inspected. This covers the standard case but not `FeePolicy::custom`
- MASM side: have `set_fee_policy` assert the incoming policy prices the config-note root before activating it, but it might be more work to inspect all the roots. Also, I think `set_fee_policy` should be agnostic to its contents, with the responsibility of constructing the right policies on the caller (and on the Rust helpers)
- Alternatively, exempt the config note from pricing entirely in `collect_sponsored_fees`. I'd try to avoid that path, though.