test: use cheaper quorum setup in governance ChainLocks test

[thepastaclaw]

Issue being fixed or feature implemented

feature_governance_cl.py only needs a signing-capable ChainLocks quorum before exercising governance behavior. It currently builds a full DIP0024 rotation cycle even though regtest ChainLocks use llmq_test.

What was done?

Replace mine_cycle_quorum() with mine_quorum() and document why rotation setup is unnecessary. The existing ChainLock wait still proves that the quorum is ready before the governance assertions begin.

How Has This Been Tested?

• python3 -m py_compile test/functional/feature_governance_cl.py
• git diff --check upstream/develop...HEAD
• Exact-head code review: ship, zero findings
• Six balanced A/B functional runs using the same local dashd build, alternating baseline and candidate with unique datadirs and port seeds; all runs passed

Variant	Runs (seconds)	Median
upstream/develop	36.570, 32.828, 32.536	32.828s
This PR	30.440, 25.688, 26.723	26.723s

Median improvement: 6.105 seconds (18.6%).

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone

[thepastaclaw]

✅ Final review complete — no blockers (commit 5cdc3b2)

[thepastaclaw]

Final validation — Codex + Sonnet

This is a minimal, correct test-only change swapping mine_cycle_quorum() for the cheaper mine_quorum() in feature_governance_cl.py. I confirmed regtest's llmqTypeChainLocks is LLMQ_TEST (chainparams.cpp:926) matching mine_quorum()'s default llmq_type_name="llmq_test"/llmq_type=100, and that the function mines through signing maturity by default, so the subsequent all-node ChainLock wait still genuinely proves readiness. All four reviewer lanes (Codex general/commit-history, Claude/Sonnet-strict general/commit-history) independently found zero issues, and there is no prior review history or CodeRabbit content to reconcile.

Source: reviewers codex/general=gpt-5.6-sol(completed); codex/dash-core-commit-history=gpt-5.6-sol(completed); claude/general=claude-sonnet-5(failed); claude/dash-core-commit-history=claude-sonnet-5(failed); claude/general=claude-sonnet-5(failed); claude/dash-core-commit-history=claude-sonnet-5(failed); claude/general=claude-sonnet-5(completed); claude/dash-core-commit-history=claude-sonnet-5(completed); verifier=claude/final-verifier=claude-sonnet-5(completed); coordinator=openclaw-agent/cliproxy/gpt-5.6-sol(orchestration-only).

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — dash-core-commit-history (completed)
• Verifier: claude-sonnet-5 — final-verifier
• Sonnet reviewers: claude-sonnet-5 — general (failed), claude-sonnet-5 — dash-core-commit-history (failed), claude-sonnet-5 — general (failed), claude-sonnet-5 — dash-core-commit-history (failed), claude-sonnet-5 — general (completed), claude-sonnet-5 — dash-core-commit-history (completed)

Note: GitHub does not allow PastaClaw to submit an approval or request changes on their own PR, so the canonical verifier result is transported as a COMMENT review.

[thepastaclaw]

The TSAN failure is unrelated pre-existing flakiness in feature_protx_version.py, so this PR is proper as-is and the branch has not been changed.

#7498 changes only test/functional/feature_governance_cl.py. The failing test exhausted all three retries and ultimately timed out at feature_protx_version.py:241, waiting 240 seconds for a revoked masternode's getconnectioncount() to reach zero. The immediately preceding develop base SHA (2e52d33fa3bde2e4bf70152df8e126f0db11d989) failed its own TSAN run with the exact same test, line, predicate, and timeout: https://github.com/dashpay/dash/actions/runs/30483914944/job/90688072625

Tracked as the renamed test's latest occurrence in #6702. Maintainers can rerun CI if desired; no commit, push, rebase, or retrigger was made here.

[thepastaclaw]

CI note: linux64_tsan-test failed on an unrelated pre-existing flake in feature_protx_version.py (test_revoke_protx waiting for getconnectioncount() == 0 timed out after 240s). This PR only changes feature_governance_cl.py quorum setup and does not touch ProTx revoke/connection drain paths. I do not have rights to rerun failed jobs here; a maintainer rerun of the failed TSAN job should be enough if this remains the only red check.