Prevent stale voting commands from overwriting newer voter intent

Outcome Make the canonical Rust command boundary reject or harmlessly replay stale conflicting commands for the same voter, not just stale HTML responses. Confirmed gap - CastVote contains only schema_version and choice; manual vote is the same shape. There is no per-voter expected state, intent generation, nonce or command ordering token. - The per-run lock serializes arrival order, but arrival order is not user-intent order. An older delayed/replayed vote can arrive after a newer choice and change canonical state again within the same run. - A delayed secretary manual-vote command can overwrite a later self-cast vote and restore manual attribution, contradicting the intended voter-override rule. - The 60-second HMAC timestamp authenticates requests but does not prevent exact replay. Existing PostgreSQL concurrency coverage races different voters, not conflicting commands for one voter. Acceptance criteria - Define a minimal per-voter ordering or compare-and-set contract that preserves the newest accepted user intent without introducing a Rails command ledger, global-revision conflicts between different voters, dual writes or asynchronous retries. - Exact replay is a no-op. A stale self-vote cannot overwrite a newer self-vote. A stale manual vote cannot overwrite a later self-cast vote or restore cleared attribution. Current valid manual corrections and subsequent voter override remain supported. - Rails forms/responses carry only server-validated ordering state; stale/multi-tab/reconnect submissions repair from the authoritative snapshot with a clear result. - Real PostgreSQL tests race same-voter self/self, manual/manual and manual/self commands in both arrival orders, including lost responses and replay inside the signature window. Rails request and authenticated multi-session browser regressions verify the resulting selected state and attribution.