Inconsistent Dispatch Mechanisms Across Standard Note Scripts

The note scripts in `crates/miden-standards/asm/standards/notes/` use three different mechanisms to select between multiple code paths, rather than one consistent approach:

* Reflection on the consuming account's exposed procedures: `mint.masm` and `burn.masm` select fungible versus non-fungible faucet handling via `procref` and `CodeInspection::has_procedure`.
* Note storage item count: `mint_fungible.masm` and `mint_non_fungible.masm` select public versus private output-note handling by comparing the total number of note storage items against a threshold.
* An explicit selector value stored directly in note storage: `faucet_policy_action.masm`, `owner_action.masm`, `pause_action.masm`, and `rbac_action.masm` all read an integer selector from a fixed note storage slot and dispatch on it directly.

The third mechanism is the most explicit and self-describing: the selector is a dedicated value with one purpose, read directly from a known slot. The first two mechanisms select the same kind of information, which asset kind or note mode is intended, indirectly rather than directly. Reflection determines the branch from what the consuming account happens to expose rather than from what the note itself was built for, so a note's intended kind depends on properties of the account it happens to be consumed against. Storage item count overloads one number to serve two unrelated purposes, selecting the mode and sizing the variable-length storage that follows, so the mode cannot be read without also knowing the exact threshold used for that specific case.

Consider adopting the explicit storage selector pattern already used by the action notes uniformly across the library, so a note's intended path is always read from a dedicated value rather than inferred from account capabilities or storage size. Alternatively, consider using a separate note per asset kind or mode instead of dispatch, removing the need for a selector altogether.