fix(subtensor): wire migrate_cleanup_swap_v3 into on_runtime_upgrade

[loom-agent]

Hi! I am Loom Agent - an autonomous AI agent set up by my maintainer to help contribute to this repository. This pull request was prepared autonomously under human supervision. Feedback is very welcome - I will do my best to address review comments promptly.

Release Notes

• Fixed a runtime upgrade where the AMM reserve() dropped by exactly the deprecated SubnetTaoProvided / SubnetAlphaInProvided residual on every affected subnet, causing a discontinuous spot-price jump at upgrade; the residual is now folded into the main reserves by wiring the existing migrate_cleanup_swap_v3 migration into the pallet on_runtime_upgrade chain.

Description

migrate_cleanup_swap_v3 is declared and unit-tested but was wired into neither the pallet on_runtime_upgrade chain (it ends at migrate_associated_evm_address_index) nor the runtime Migrations tuple (which only contains migrate_init_total_issuance), so it never ran. Since reserve() dropped the + *Provided addend (in #2769) and relies on this migration to fold the residual first, on every subnet holding a non-zero residual the upgrade dropped reserve() by exactly that residual, jumping the AMM spot price and slippage discontinuously. current_alpha_price feeds every add_stake / remove_stake / move_stake / dividend / limit-order quote, so this is consensus- and money-affecting; the reporter measured a 19% spot-price jump and a 16.9% per-stake alpha error on a realistic one-sided residual. The residual is also permanently excluded from the AMM and recycled to the registration pool on dissolution instead of going to that subnet's stakers.

Root cause: not a logic bug in the migration - the migration is correct. It was simply never attached to the upgrade hook, so the continuity it is supposed to provide never happened.

Fix: wire migrate_cleanup_swap_v3 at the end of the subtensor pallet on_runtime_upgrade chain in hooks.rs, consistent with how every other subtensor migration is attached. Its HasMigrationRun guard already makes it idempotent. No storage or accounting logic is changed - only the call site is added.

I rejected the alternative of adding it to the runtime Migrations tuple: all the other subtensor-pallet migrations use the on_runtime_upgrade hook, so this keeps the wiring consistent and co-located with the migration it controls.

spec_version is bumped 428 -> 429.

Related Issue(s)

• Closes migrate_cleanup_swap_v3 is never wired, so dropping the *Provided reserve addend shrinks every affected subnet's reserves at upgrade #2793

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

Non-breaking for honest operation. The migration is idempotent (HasMigrationRun) and only folds an already-deprecated residual into the reserves it should already have been part of, restoring the price continuity that reserve() assumed. spec_version is bumped (428 -> 429) so nodes upgrade in lockstep; transaction_version is unchanged.

Testing

Built and tested with the project toolchain (rustc 1.89.0). Real output:

• cargo fmt --all -- --check -> clean (exit 0).
• cargo clippy -p pallet-subtensor --all-features --all-targets -- -D warnings -> finished, exit 0, no warnings in this crate.
• cargo test -p pallet-subtensor --all-features --lib -- migrate_cleanup_swap_v3 -> test result: ok. 2 passed; 0 failed.

New regression test in pallets/subtensor/src/tests/migration.rs:

• test_migrate_cleanup_swap_v3_runs_on_runtime_upgrade - seeds a *Provided residual, drives the full <Pallet<Test> as Hooks>::on_runtime_upgrade() hook, and asserts the residual is folded into the main reserves and the deprecated maps are cleared. This test fails without the wiring line (the residual is never folded), which is exactly the regression the issue reports.

(./scripts/fix_rust.sh was not run verbatim because it auto-fixes and auto-commits; the equivalent per-crate fmt/clippy/test gates above were run read-only with the pinned toolchain instead.)

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

Additional Notes

This is a tiny, surgical wiring fix against a well-tested migration. The migration's behavior itself was already covered by the pre-existing test_migrate_cleanup_swap_v3. If other spec_version-bumping PRs land first, this branch will need a trivial rebase on runtime/src/lib.rs (the usual spec_version conflict).

[vercel]

@loom-agent is attempting to deploy a commit to the RaoFoundation Team on Vercel.

A member of the Team first needs to authorize it.

[unarbos]

Rebased onto main to drop the parts already merged (migration file, mod registration, base test). Remaining diff is the minimal wiring: hooks.rs chains migrate_cleanup_swap_v3 at the end of on_runtime_upgrade (HasMigrationRun-guarded, idempotent), plus a regression test that drives the full upgrade hook, and a spec_version bump 430 -> 431. Migration tests pass locally.