app: register v1.20.2 migration-only upgrade handler

[mateeullahmalik]

Behavior change

Registers the v1.20.2 software-upgrade handler and routes it through the standard Cosmos SDK module migration manager.

Rationale

Testnet is currently running v1.20.1. The history-preservation fixes in the parent PR require a named v1.20.2 handler so Cosmovisor can resume block production at the governance-planned upgrade height.

State-machine impact

• State keys: only keys changed by moduleManager.RunMigrations when an installed module consensus version requires migration.
• CheckTx / DeliverTx: no new transaction path.
• BeginBlock / EndBlock: no new behavior outside the one-time upgrade callback at the planned height.
• Determinism / replay: standard deterministic SDK upgrade-handler execution; no wall-clock, network, or filesystem dependency.
• Partial failure: an error aborts the upgrade block; no custom repair loop or best-effort mutation.
• Migration: standard module migrations only.
• Historical repair: none. This PR intentionally does not scan or repair already-corrupted records.

Risks

• An unregistered or misnamed handler would halt Cosmovisor nodes at the upgrade height.
• A module migration error would prevent the upgrade block from committing.

Rollback

Before the upgrade height, withdraw/cancel the proposal or deploy a corrected binary. After execution, use the established chain rollback/governance recovery procedure; this PR adds no custom reversible state transform.

Verification

• Upgrade registration tests
• Handler execution tests
• Exact local rehearsal: v1.20.1 -> v1.20.2, five validators, continued block production
• Parent protocol PR: fix(evmigration): preserve SuperNode history during migration #196

Stack order

1. fix(evmigration): preserve SuperNode history during migration #196 — protocol/history preservation
2. this PR — v1.20.2 handler
3. operator tooling/runbooks follow-up

[mateeullahmalik]

Closing in favour of #199, which owns app/upgrades/v1_20_2.

Why

Both PRs branch off #196 and both create app/upgrades/v1_20_2/upgrade.go plus a registration in app/upgrades/upgrades.go. They conflict textually, and merge order would silently decide which implementation ships.

That matters because this PR's handler is:

case upgrade_v1_20_2.UpgradeName:
    return UpgradeConfig{
        Handler: standardUpgradeHandler(upgrade_v1_20_2.UpgradeName, params),
    }, true

No StoreUpgrade. That is exactly the implementation I shipped first in #199, and the mainnet-shaped devnet rehearsal killed it twice:

panic: failed to load latest version: version of store evmigration mismatch
       root store's version; expected 155 got 0; new stores should be added
       using StoreUpgrades

panic: error initializing evm coin info: denom metadata aatom could not be found

Every validator crash-looped on a faithful lumera-mainnet-1 replica — v1.12.0 release artifact, genesis trimmed to the v1.12.0 module set, audit v2, no EVM modules. Correct for testnet (v1.20.0 already mounted the stores), fatal for mainnet (nothing has).

#199's version declares the five EVM store additions, routes through the add-only store loader, and uses a state-driven handler that delegates to the v1.20.0 bring-up when the EVM stack is absent — verified green on both the single-hop 1.12.0 -> 1.20.2 and two-hop 1.12.0 -> 1.20.1 -> 1.20.2 paths, plus the testnet-shaped 1.20.1 -> 1.20.2.

Nothing is lost

This PR is 34 lines across 4 files, all of it v1_20_2. Its only test is:

func TestUpgradeName(t *testing.T) {
    require.Equal(t, "v1.20.2", UpgradeName)
}

#199 carries 6 tests over the same package, including TestV1202UpgradeNameMatchesDirectory, which covers that assertion and additionally guards the UpgradeName-vs-git-tag trap:

• TestV1202IsRecognizedAsKnownUpgrade
• TestV1202MountsEVMStoresForMainnetOneHop
• TestV1202UsesAddOnlyStoreLoader
• TestAuditConsensusVersionHasCarryingUpgrade
• TestV1202IsRegistered
• TestV1202UpgradeNameMatchesDirectory

So #199 strictly supersedes this branch. No unique work is being dropped.

Follow-up

#197 (operator runbooks) is stacked on this branch and will be rebased onto #199.