Clean up vote state handler after v4 activation

[buffalojoec]

Once vote_state_v4 is activated on all networks, we can
significantly simplify handler.rs by removing the trait-based
dispatch and consolidating into the VoteStateHandler API.

Motivation

The current architecture in handler.rs was built to support
dynamic V3/V4 dispatch during the migration period. Once that's
done, the complexity is unnecessary. Specifically:

• VoteStateHandle trait — ~25 methods, many of which are
  no-ops on V3 (collectors, BLS, pending rewards).
• PreserveBehaviorInHandlerHelper — The
  V3 { check_initialized } vs V4 enum exists solely to preserve
  the V3 deserialization
  path's init-check behavior.
• Default trait methods — process_timestamp,
  process_next_vote_slot, increment_credits, etc. dispatch
  through getter/setter accessors. Simpler as direct methods.

Note that we would retain TargetVoteState and the inner match
statements within VoteStateHandler, since it makes adding a V5
or beyond extremely trivial, since the compiler will direct you where
you need to add V5 access implementations.

Proposed changes

1. Remove VoteStateHandle trait. Inline everything into
   impl VoteStateHandler. Default trait methods become regular
   methods that call other methods on Self.

2. Simplify VoteStateHandler internals. Drop the
   TargetVoteState::V3 variant (or keep behind #[cfg(test)]).
   Each method operates on VoteStateV4 directly. If we ever
   need V5, re-adding a variant gives us compile-time match
   exhaustiveness — same role the trait played, but simpler.

3. Remove PreserveBehaviorInHandlerHelper. Replace
   get_vote_state_handler_checked with a straightforward
   deserialize + init check. V4 always checks initialization.

Lastly it would be good to keep tests dynamic somehow, so that
whoever may add a V5 doesn't have to go and add back all of the
#[test_case] attributes and parameters, but we'll see what this
looks like as we implement the cleanup.