[Feature] V2: implement reveal phase and commitment verification

[collinsezedike]

Summary

Implement the reveal phase: once registration closes, third-party positions disclose the side they committed to during registration, and the contract verifies each disclosure against its stored commitment.

What to build

On registration cutoff (soft deadline reached with no further qualifying deposits, or hard deadline reached), transition the assertion's phase to Reveal with a deadline at reveal_opened_at + policy.reveal_duration_secs. Freeze W (the eligible total) at this point; no further deposits or top-ups are accepted after this transition.

reveal(voter: Address, id: u64, choice: bool, salt: BytesN<32>)

• Requires voter's authorization.
• Looks up Position(id, voter). Reject if no position exists, or if this position has already revealed.
• Recomputes H(canonical_encode("THOLOS_V2_VOTE", network_id, contract_address, policy_hash, assertion_id, round, voter, choice, salt)) and rejects if it doesn't match the commitment stored at registration time.
• On success, adds this position's full weight to agree_weight if choice agrees with the asserted outcome, or disagree_weight otherwise. Marks the position revealed so it can't reveal twice.
• The asserter's and disputer's fixed positions are not separately "revealed" via this call: they're already known (public by construction) and should be counted into the relevant tally, and into revealed_weight, exactly once, at the point reveal opens.

Note for clients (document this, don't just assume it): a client must read the on-chain phase transition to Reveal before submitting a reveal transaction. Guessing that the soft cutoff has passed is unsafe, a rejected reveal transaction still publishes its (choice, salt) preimage on-chain even though it failed, while an anti-sniping extension might mean registration is still actually open.

Depends on

#66 (positions and commitments must exist from registration).