Implement result_type parameter in get_contested_resource_vote_state functions

[thephez]

Expected Behavior

The result_type parameter in WASM SDK get_contested_resource_vote_state functions should properly map to the protobuf ResultType enum and control what data is returned in the response.

Current Behavior

The result_type parameter is declared but unused (prefixed with _) in both:

• get_contested_resource_vote_state_with_proof_info
• get_contested_resource_vote_state

Instead, the code incorrectly uses allow_include_locked_and_abstaining_vote_tally to set the gRPC result_type field, which conflates two independent concerns.

Possible Solution

1. Map string parameter values to protobuf enum codes:
   • "documents" → 0 (DOCUMENTS)
   • "vote_tally" → 1 (VOTE_TALLY)
   • "documents_and_vote_tally" → 2 (DOCUMENTS_AND_VOTE_TALLY)
2. Add validation for invalid input values
3. Keep allow_include_locked_and_abstaining_vote_tally as independent boolean flag

Steps to Reproduce

1. Check function signatures in packages/wasm-sdk/src/queries/voting.rs around lines 357 & 718
2. See that _result_type parameters are unused
3. See lines ~419 & ~780 where result_type is set using the boolean flag

Context

This issue was discovered while fixing build warnings. The parameter exists in the public API (TypeScript definitions, documentation) but doesn't actually function. This creates confusion and prevents proper use of the underlying protobuf functionality.

Your Environment

• Version: Current v2.1-dev branch
• Component: WASM SDK voting queries (packages/wasm-sdk/src/queries/voting.rs)