feat(new-protocol): send vote2 as soon as cert1

[mrain]

Closes #<ISSUE_NUMBER>

This PR:

This PR does not:

Key places to review:

[claude]

Claude finished @mrain's task in 3m 42s —— View job

---

Code Review: feat(new-protocol): send vote2 as soon as cert1

• Read existing review comments
• Read CLAUDE.md for repo guidelines
• Analyze PR diff and changed files
• Review consensus.rs changes
• Review coordinator.rs changes
• Review test changes
• Post review feedback

---

Summary

This PR decouples vote2 from block reconstruction, splitting maybe_vote_2_and_update_lock into two independent branches:

1. Vote2 — fires as soon as cert1 is available, using cert1's data directly (no proposal or reconstruction needed)
2. Lock-update / ViewChanged / SendCertificate1 — still requires proposal + block availability (reconstruction or self-built block)

Additionally, the payload commitment verification that was in consensus is moved to the coordinator, which validates the reconstructed commitment against the proposal before emitting BlockReconstructed. A new block-availability guard is also added to maybe_decide.

What looks good

• Core decoupling is clean. The critical change — removing the early voted_2_views return that previously short-circuited the entire function (including lock-update) — is correct and well-reasoned. The two branches are now properly independent.
• Data sourcing from cert1 is sound. cert1 aggregates vote1s that already verified the proposal, so cert1.data.leaf_commit is the correct commitment. Using cert1's epoch/block_number (which mirror the proposal fields) avoids the need to wait for the proposal.
• Coordinator-side validation is a good separation of concerns. Moving the reconstructed_commitment != proposal_commitment check to the coordinator means consensus can trust any BlockReconstructed input it receives.
• Test coverage is excellent. test_lock_update_fires_when_recon_arrives_late precisely validates the split behavior: vote2 fires early, lock-update defers, reconstruction unblocks lock-update, and vote2 doesn't double-fire. The use of count_matching with before/after snapshots is robust.

Issues flagged (inline comments posted)

1. Potential race in coordinator (coordinator.rs:446-455): If VID reconstruction completes before the proposal arrives at the coordinator, the reconstructed payload is permanently dropped with no retry. The lock-update and decide paths would stall for that view. See inline for details.

2. Silent skip when cert1 fields are None (consensus.rs:1280-1283): Vote2 silently doesn't fire if cert1.data.epoch or cert1.data.block_number is None. A debug log would help diagnose this.

3. Minor test message accuracy (tests/consensus.rs:363-368): Assertion message says "cert1 + proposal" but vote2 only depends on cert1.

Overall this is a well-structured change that correctly decouples the latency-critical vote2 path from reconstruction. The main item to consider is the reconstruction-before-proposal race in the coordinator.

[gemini-code-assist]

Code Review

This pull request refactors the consensus mechanism to allow Vote2 to be sent immediately upon receiving a certificate and proposal, while deferring lock updates and decisions until the block is locally available. Review feedback identifies a safety risk in consensus.rs due to the removal of commitment checks between proposals and reconstructed blocks. Furthermore, a liveness issue was found in coordinator.rs where reconstructed blocks are dropped if the proposal is missing, which could stall the protocol in asynchronous environments.