Classify the two emission-gate AdminUtils calls in the proxy call groups

[philipmaymin]

Description

sudo_set_emission_bar_quantile and sudo_set_emission_gate_exponent (pallets/admin-utils/src/lib.rs:2021 and :2042) are absent from the runtime proxy call inventory and from the SDK coverage list. Both gates are red on main.

Runtime. cargo test -p node-subtensor-runtime proxy_filters fails four tests:

proxy_filters::call_groups::tests::all_call_groups_cover_runtime_call_metadata
proxy_filters::tests::non_critical_is_everything_but_sudo_and_critical_ops
proxy_filters::tests::non_fungible_is_everything_but_value_movement_and_key_swaps
proxy_filters::tests::non_transfer_is_everything_but_transfers_and_coldkey_swaps

The first names the shortfall directly:

missing from AllCalls (2):
  AdminUtils::sudo_set_emission_bar_quantile
  AdminUtils::sudo_set_emission_gate_exponent
extra in AllCalls (0):
duplicates in AllCalls (0):

The other three are downstream of the same gap: they assert allowed_calls(...) == all_runtime_calls() - denied, and unclassified calls break that identity.

SDK. runtime-checks.yml:504 runs codegen.check --coverage, which reports the same two calls as having no status. _generated/calls.py was regenerated for spec 440 and does contain both, so the drift gate was satisfied; the classification step is what was missed, in both places.

What this changes

Both extrinsics are ensure_root global emission-gate parameters, so they go in RootConfigCalls next to the sudo_set_tao_flow_* setters they were added alongside, and in RAW_ONLY["AdminUtils"] next to the other root-origin sudo_set_* entries.

There is a second cost beyond the red CI. all_call_groups_cover_runtime_call_metadata is the mechanism that stops a newly added extrinsic from silently landing in a permissive proxy group. It cannot do that job while it is already failing, because a new failure is indistinguishable from the existing one.

Related Issue(s)

None filed.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other (please describe):

Breaking Change

None. Both calls are root-origin only, so no proxy type gains reachable authority it did not already have through sudo.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run ./scripts/fix_rust.sh to fix formatting and clippy issues
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

No test added: the completeness test already existed and was failing. This makes it pass.

I could not run codegen.check --coverage locally (bittensor_core is not built in my environment), so the SDK half of this rests on your CI. The runtime half I ran.

Additional Notes

If the grouping choice is wrong I will move them. RootConfigCalls matched both the origin (ensure_root) and the neighbours these two arrived with, but you know the intent behind those groups better than I do.

[vercel]

@philipmaymin is attempting to deploy a commit to the RaoFoundation Team on Vercel.

A member of the Team first needs to authorize it.