L-17: `cleanup_pubkey_and_scheme_id_mapping` Trusts Unvalidated Approver Counts and Omits Configuration Reconciliation

The `cleanup_pubkey_and_scheme_id_mapping` procedure in `multisig.masm` is declared `pub`, making it a reusable entry point for any module that links against the `miden::standards::auth::multisig` library. It clears the approver entries in the range `[new_num_of_approvers, init_num_of_approvers)` from the `APPROVER_PUBLIC_KEYS_SLOT` and `APPROVER_SCHEME_ID_SLOT` maps, but it performs no validation beyond asserting that its two arguments are `u32` values, and it does not modify `THRESHOLD_CONFIG_SLOT` or `PROC_THRESHOLD_ROOTS_SLOT`.

Its correctness therefore depends entirely on an undocumented caller contract: `init_num_of_approvers` must equal the previously committed approver count, and the threshold configuration must have already been updated to a value that remains reachable with the reduced signer set. Within the library these guarantees are supplied only by `update_signers_and_threshold`, which reads the previous count from storage, [asserts that the threshold does not exceed the new approver count and that existing procedure thresholds remain reachable](https://github.com/0xMiden/protocol/blob/2ef8056323df258917d119383a7cdd49b064d88a/crates/miden-standards/asm/standards/auth/multisig.masm#L247-L264), and only then invokes the cleanup routine. None of these constraints are enforced or documented by `cleanup_pubkey_and_scheme_id_mapping` itself; its documentation describes only the meaning of the two arguments, not the trust placed in them.

As a result, a downstream component that reuses this procedure without correspondingly updating the threshold configuration can leave the multisig in an inconsistent state where the stored configuration still claims more approvers than remain in the maps and the required threshold exceeds the number of available signers. In that state no set of signatures can satisfy the authentication check, rendering the account permanently unusable. Because the procedure belongs to a shared library intended for reuse, this footgun is exposed to any consumer that does not replicate the invariant checks currently implemented only in `update_signers_and_threshold`.

Consider validating the inputs directly within `cleanup_pubkey_and_scheme_id_mapping`. Alternatively, if the procedure is intended solely as an internal helper, consider restricting its visibility and documenting the caller contract along with the storage invariants it assumes.