Implement on-chain dispute resolution with arbitration voting

[Kingsman-99]

Overview

Build a full dispute lifecycle into the contract. Any payer on an invoice can open a dispute before release. A configurable set of arbitrators votes to resolve or reject. Funds are frozen during dispute and released/refunded according to the outcome.

Requirements

• open_dispute(env, invoice_id, payer, reason: String) — opens a dispute, freezes the invoice (cannot release/refund while open)
• vote_dispute(env, invoice_id, arbitrator, approve: bool) — arbitrator casts a vote; requires the caller to be in the stored arbitrator set
• resolve_dispute(env, invoice_id) — callable by anyone once quorum is reached; resolves the invoice according to majority vote (approve → release, reject → refund)
• Dispute state stored under a new dispute_key(invoice_id) storage key
• Emit DisputeOpened, DisputeVoteCast, DisputeResolved events
• Admin can configure arbitrator_set and quorum_threshold (e.g. 2-of-3)
• Write unit tests for: open → vote → resolve (approve path), open → vote → resolve (reject path), duplicate vote rejected, non-arbitrator vote rejected, dispute on non-existent invoice

Acceptance Criteria

• All three entry points implemented
• Frozen invoice cannot be released or refunded during open dispute
• Quorum logic correct for configurable N-of-M threshold
• Storage snapshot test updated with new dispute_key
• All existing tests pass
• cargo test --workspace passes with zero failures
• cargo clippy --all-targets -- -D warnings produces zero warnings

Definition of Done

All CI checks must pass before the PR is reviewed.

[nurudeenheroic]

Hi! I can handle this issue and ensure it meets the requirements.