fix(bft): make GetLeadingVote deterministic on equal voting power

[amathxbt]

Bug

bft/vote.go's GetLeadingVote() selects the vote set with the most voting power using >= while iterating over a Go map:

for _, voteSet := range b.Votes[b.View.Round][...] {
    if voteSet.TotalVotedPower >= maxVotes {
        m, maxVotes = voteSet.Vote, voteSet.TotalVotedPower
    }
}

Go map iteration order is randomized. When two payload hashes have equal voting power, GetLeadingVote() can return different “leading” votes for the
same local vote set.

This function is currently used for consensus status reporting, not for QC construction or consensus advancement, but deterministic behavior is
still preferable for consistent debugging, RPC output, and tests.

## Fix

Iterate with the payload hash key and use a deterministic tie-break. Higher voting power still wins; when voting power is equal, the
lexicographically smallest payload hash wins:

if voteSet.TotalVotedPower > maxVotes ||
    (voteSet.TotalVotedPower == maxVotes && (m == nil || payloadHash < maxPayloadHash)) {

This removes map-iteration randomness from GetLeadingVote() for identical local vote sets.

## Impact

Low — this stabilizes leading-vote reporting in equal-power ties. It does not appear to affect consensus safety or liveness because consensus
operation uses GetMajorityVote(), not GetLeadingVote().

[andrewnguyen22]

The critical severity of this finding is overstated. This is not used in operation - is decorative for the RPC only.

This is really low-priority cleanup

The PR should be downgraded and reworded. I’ll approve it - but will update the PR description

[amathxbt]

Acknowledged updated the PR description to downgrade severity from critical to low and clarify this is RPC/display-only (not used in consensus logic). Appreciate the context.