Allow subnet owners to set minimum childkey take per subnet

[gztensor]

Description

This change adds subnet-specific minimum childkey take support.

A new MinChildkeyTakePerSubnet storage map allows each subnet to define its own minimum childkey take. The effective minimum childkey take for a subnet is now:

max(global MinChildkeyTake, MinChildkeyTakePerSubnet[netuid])

This preserves the global protocol floor while allowing subnet owners to make their subnet stricter.

Behavior

• The global MinChildkeyTake remains the protocol-wide lower bound.
• A subnet owner can set a higher minimum childkey take for their subnet.
• A subnet owner cannot set the subnet minimum below the global minimum.
• set_childkey_take now validates against the effective subnet minimum.
• get_childkey_take(hotkey, netuid) clamps stored values upward to the effective minimum, so existing low stored values cannot bypass a newly raised subnet floor.

New Storage

MinChildkeyTakePerSubnet<T: Config>: StorageMap<_, Identity, NetUid, u16, ValueQuery>

New Helpers

set_min_childkey_take_for_subnet(netuid, take)
get_min_childkey_take_for_subnet(netuid)
get_effective_min_childkey_take(netuid)

New Admin Call

sudo_set_min_childkey_take_per_subnet(origin, netuid, take)

Callable by root or the subnet owner through pallet-admin-utils.

Rationale

This gives subnet owners an economic lever to discourage low-take childkey strategies on their subnet, while preserving root governance’s global minimum as an invariant floor.

The global minimum is not replaced. Instead, the subnet-specific value can only make the effective minimum stricter.

Tests

Added tests covering:

• subnet minimum enforcement in set_childkey_take
• clamping of existing stored childkey take values through get_childkey_take
• subnet owner authorization
• rejection of subnet minimum values below the global minimum

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):

Checklist

• 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 ensure my code is formatted and linted correctly
• 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