governance-dao: vote tally accumulation and quorum calculation use unchecked arithmetic

[gboigwe]

Summary

cast_vote's vote-tally accumulation and finalize_proposal's quorum calculation both use plain unchecked arithmetic on values that could be large for a governance token with substantial supply.

Location

contracts/governance-dao/src/lib.rs: cast_vote's proposal.votes_for += power / votes_against += power / votes_abstain += power; finalize_proposal's let total_votes = proposal.votes_for + proposal.votes_against + proposal.votes_abstain; and let quorum_met = (total_votes * 10_000) >= (total_supply * (proposal.quorum_bps as i128));

Problem

None of these additions/multiplications use checked_add/checked_mul. votes_for/votes_against/votes_abstain accumulate across every vote cast on a proposal with no overflow guard, and the quorum check multiplies total_votes and total_supply by 10_000 — for a token with a large total supply (governance tokens commonly have supplies in the billions/trillions with decimals), this multiplication has real overflow potential, consistent with the same class of issue already found and fixed in other contracts in this workspace (revenue-settlement, payment-processor, token-bridge).

Impact

Medium-high: an overflow here would either panic (halting proposal finalization) or, in the worst case, wrap and produce an incorrect quorum determination — both undesirable for a governance-critical calculation.

Acceptance Criteria

• Vote tally accumulation in cast_vote uses checked_add
• The quorum multiplication in finalize_proposal uses checked_mul, failing cleanly on overflow rather than panicking uninformatively or wrapping
• A regression test demonstrates correct behavior near realistic large-supply boundaries
• cargo test -p pulsar-governance-dao passes

Suggested Approach

Follow the same checked-arithmetic pattern already applied to revenue-settlement/payment-processor/token-bridge in earlier fixes for this exact class of issue.