Vote polls: identity contender poll kind without Lock, plurality, first-wins tie-break (moderation teams A1)

[QuantumExplorer]

Part of #4865 (decentralized moderation teams). Item A1 of the PR split. Wave 1: no dependency, can start now.

Summary

Add a second kind of masternode vote poll: an identity contender poll keyed by an arbitrary resource, with no Lock choice, resolved by plurality with a first-wins tie-break. It serves the initial election of a moderation team and stage 2 of a challenge ("which challenger?"). DPNS contested documents are untouched.

Decisions implemented: D21, D22, D23, D43, D52, D53, D56 in #4865.

Current behaviour

VotePoll in packages/rs-dpp/src/voting/vote_polls/mod.rs has one variant, ContestedDocumentResourceVotePoll. Everything downstream is written for it: the storage forms and trees under packages/rs-drive/src/drive/votes/, the resolver in resolved/vote_polls/, the tally, and check_for_ended_vote_polls in packages/rs-drive-abci/src/execution/platform_events/voting/, which matches only on that variant. Its tie-break awards the latest contender (max_by(created_at, block height, core block height, id)), and it has a Lock choice.

Scope

• A new VotePoll variant: a contender poll over identities, keyed by a resource path chosen by the caller (the moderation PRs key it by the moderated contract id). Contenders are identities, added while the poll is in its join phase.
• Vote choice: towards an identity or abstain. No Lock.
• Resolution at the end of the vote window: the contender with the highest tally wins by plurality, no minimum. With zero votes the first contender wins. Ties break to the first contender: earliest block time, then block height, then the contender's document id (D53). Use min_by, the opposite of the shipped DPNS ordering.
• If the join phase ends with a single contender, the poll resolves at once, with no vote phase (D23).
• Storage: contenders, votes, end-date index and stored result for the new kind, in the existing votes tree layout, plus the clean-up operations. The existing contested-document paths do not change.
• check_for_ended_vote_polls dispatches on the variant. The outcome of the new kind is handed to a callback the seating PR fills in; this PR only records the winner.
• Masternode vote validation accepts the new poll kind, with the same per-vote cost and prefunded balance rules as today.
• Proof verification for the new poll's queries in rs-drive-proof-verifier, so the seating and client PRs have something to verify against.

Out of scope

• The 0.5 Dash fund and reading windows from a target contract (A3).
• Yes/no polls (A2).
• Anything that opens one of these polls (H2, H4).

Tests

• Poll with three contenders, votes split, plurality winner.
• Tie at the top resolves to the earliest contender, including two contenders in the same block, where the id decides.
• Zero votes: first contender wins.
• Single contender: resolved when the join phase ends, no vote phase.
• Clean-up leaves no keys of the poll behind; the existing DPNS tests still pass unchanged.

Coordination

A2 adds another variant to the same enum and the same match arms. Trivial conflict, merge either first.

[QuantumExplorer]

Superseded. The identity contender poll kind (#4901) is closed: the election is a contested unique resource already (D15, the charter contract's byTargetContract index), so a path-keyed poll kind duplicated the DPNS machinery. A1 is now #4907: ContestedIndexResolution::MasternodeVoteNoLocking ("resolution": 1) on the existing contested poll, with no Lock choice, plurality, a single contender awarded when the join window closes, and ties to the earliest contender for every resolution from protocol version 14 (D56 revised).