Run Hermes IBC fee-granter smoke across the v31 testnet upgrade

[juno-ai-dev]

Context

Juno v30 broke all transactions using a distinct fee granter because the custom ante options shadowed the initialized SDK feegrant keeper. The production wiring fix and defensive nil guard are merged in upstream v31 via CosmosContracts#1222 and covered by signed full-handler tests.

Before v31 moves beyond public testnet, verify the exact reported operational path: a real Hermes IBC relayer configured with fee_granter, including both packet relay and client update transactions across the upgrade.

Scope

• Configure a funded grantee relayer and distinct granter with a bounded feegrant allowance on the target testnet.
• Run Hermes with fee_granter enabled; do not use direct hot-wallet fees for the primary probe.
• Relay an ICS-20 packet and force/observe client updates before and after the v30 → exact-v31 upgrade.
• Record tx hashes, message types, fee payer/granter, gas wanted/used, allowance deltas, acknowledgements, and client heights.
• Run a direct-fee control to distinguish feegrant from general relayer failures.
• Recheck the granter balance and allowance after the test.

Acceptance criteria

• Exact v31 candidate processes signed fee-granted MsgUpdateClient transactions without panic/error.
• Packet relay/acknowledgement succeeds with Hermes fee_granter enabled.
• The granter—not the relayer signer—is charged and the allowance decreases correctly.
• Direct-fee control also succeeds.
• Evidence is attached with exact binary SHA/image digest and testnet heights/tx hashes.
• Operator notes tell relayers when to remove the hot-wallet workaround and re-enable fee_granter.

Existing evidence

• Upstream fix: feegrant fixups CosmosContracts/juno#1222
• Fork PRs: fix(ante): wire feegrant keeper into custom decorator #4 and fix(ante): reject fee granter when keeper is unset #5
• Exact v31 head 123d63d487ed879855cf75ddb659d89c64e3ae17 passes go test ./x/feepay/... ./x/feemarket/... ./app/ante/... -count=1.