[V135] fix(store): seed the ZEC signing height on a cache-wrapped store

Problem

seedZECSigningHeightV135 (v135 store migration) checks iterator.Error() after scanning the ZEC network fee voters. Store migrations run on a cache-wrapped store, and in cosmos-sdk v0.45 the cachekv merge iterator returns invalid cacheMergeIterator from Error() whenever it is no longer valid, which includes after a complete scan (store/cachekv/mergeiterator.go).

So on every node the seed logs:

fail to scan ZEC fee voters during activation  error="invalid cacheMergeIterator"

and returns before calling SetLastChainHeight. ZEC LastChainHeight keeps its pre-activation value until the first ZEC fee quorum after the 1.135.0 activation. A ZEC outbound scheduled in that window is signed against the stale height. The failure is deterministic: there is no consensus split, but the seed never runs.

The existing tests did not catch it because they run against the raw test store, whose iterator returns nil from Error() after exhaustion.

Fix

• Drop the post-loop iterator.Error() check. Decode failures are still handled inside the loop (TestMigrateV135ZECHeightDecodeFailureIsNonFatal is unchanged and passes).
• Add TestMigrateV135ZECHeightSeedsInCacheContext, which runs the seed on ctx.CacheContext(), the way store migrations do. Without the fix it fails (height stays 66000; expected 100000).

Testing

go test -tags=mocknet ./x/mayachain/ -run 'TestPackage$' -check.f 'ZECHeight' -count=1   # 5 passed
go test -tags=mocknet -parallel=1 ./x/mayachain/ -count=1                             # ok

Consensus impact: this changes what the v135 store migration writes (the ZEC height seed now applies). It is relevant only for networks that have not yet activated 1.135.0.