Network account config notes have no onchain ordering

## Summary

The standard network-account config notes (`rbac_config`, `pause_config`, `blocklist_config`, `owner_config`, `faucet_policy_config`, `faucet_metadata_config`, `allowlist_config`, `min_burn_amount_config`, `network_account_config`, `constant_fee_policy_config`) can be consumed in any order, and are all non-expiring. Because consumption order is chosen by whoever consumes the note, consuming an older note could revert the action of a newer one, e.g. add a an account to a blocklist, then remove it from the blocklist. Today, the only countermeasure is operational guidance.

Documented like this (RBAC config note), but not on all the notes:

> A created note is an unordered, unexpiring, uncancellable instruction — treat it as a standing capability and do not create role-management notes ahead of need. Consumption order is chosen by whoever consumes the note, so when rotating a role, wait for the successor's grant to commit before issuing any revoke or renounce (a note that fails because its sender currently lacks the role stays pending and revives if the sender regains it).

## Why this might warrant a standard mechanism

A few concrete failure shapes:
- Pause: an operator issues `pause`, then later `unpause`; a delayed or re-issued older `pause` lands afterward and re-pauses — or the reverse re-opens something meant to stay paused.
- RBAC: a `grant` issued ahead of need, and a later `revoke`, consumed in the wrong order, revives a membership that was meant to be removed

The operational mitigation ("don't pre-create; sequence by waiting for commitment") works, but it (a) is easy to get wrong under incident response, (b) is documented on only one of ten notes, and (c) pushes a subtle safety obligation onto every account that uses these standard notes. A reusable onchain guard would prevent misuse.

## Possible directions (for discussion)

1. Monotonic config nonce. The account stores a config sequence value (global, or per-domain); each config note commits a target sequence `N`; on consume, assert `N > stored` and advance. A stale (lower-`N`) note is rejected once any newer note applies. Needs the issuer to stamp `N` from current onchain state; would be opt-in (but I'd say installed by default where relevant) via a small standard component.
2. Expiry. A committed validity window bounds staleness by time; it is an easy fix that works in most scenarios, but does not fully replace proper ordering as with the first solution.

## Question

Do we want a reusable onchain ordering guard for all the standard config notes? Or is the operational guidance enough?