consensus: bind validator votes to block height and round

[hackobi]

Problem

Consensus validator signatures are currently created and verified over the raw block hash. The proposal RPC carries the block hash and proposer identity, but no explicit consensus round/view or canonical chain/network domain.

This leaves vote freshness and replay protection underspecified: a valid signature may be reusable outside the context in which it was produced unless the surrounding protocol provides an equivalent binding.

Required design

Define a canonical, versioned vote message that includes at minimum:

• protocol/network or chain identifier;
• block height;
• consensus round/view;
• block hash;
• signature scheme/version.

The same message must be used consistently by:

• block signature creation;
• outbound vote aggregation;
• inbound proposal verification;
• block acceptance/finality verification.

Required tests

• A signature from one block height cannot validate at another height.
• A signature from one round/view cannot validate in another round/view.
• A signature for one block hash cannot validate for a conflicting hash.
• Cross-network/domain replay is rejected.
• Stale proposals and partition/rejoin messages are rejected safely.
• Mixed-version behavior is explicit and fail-closed.

Dependencies and constraints

• Do not merge a protocol change until the canonical chain/network identifier and round/view semantics are confirmed.
• Keep this work separate from PR fix(consensus): restrict collected signatures to shard members #986, which addresses shard-membership filtering.
• Require multi-node and adversarial coverage before enabling Petri on the mainnet path.