fix(thorchain): stop treating a superseded keygen as pending

What

hasPendingKeygen now scans keygen blocks newest first and stops at the first block whose keygen of this type has already produced an active or init vault. Older keygens of that type are superseded and no longer count as pending. Keygens in the same block (split Asgard groups) are still each checked, and the validity window still applies to unresolved keygens.

Why

An older keygen whose vault has since retired can no longer be matched by membership, so it read as pending again for up to ChurnRetryInterval - 1 blocks and blocked the next churn of that type.

In test-simulation the genesis XMR keygen (around block 65) was still inside the 364-block XMR window when BondYield-ChurnOut churned at block 422–428. The churn logged Skipping XMR FROST keygen due to pending keygen, rotated only the Asgard vault, and the leaving node stayed Active as an XMR monovault member until the next retry tick (jobs 17179508743, 17244699867).

Consensus

This changes churn scheduling in the current validator manager, the same place recent churn fixes such as 161ba2ad landed. Regression exports are not expected to change; this MR's test-regression run is the check.

Testing

• New case in manager_validator_current_test.go fails before the change and passes after.
• go test -tags=mocknet ./x/thorchain/... and lint pass.

Found while investigating the test-simulation failures still flaking in October 2026.

🤖 Generated with Claude Code