Instrument proposer QBFT lifecycle and round transitions

[diegomrsantos]

Summary

Instrument the proposer QBFT lifecycle so we can explain time spent inside consensus, especially round churn and bad-round recovery.

Motivation

Knowing that a proposer duty was slow is not enough. We need to know whether the time was spent waiting for the first proposal, burning a round timeout, advancing rounds, or deciding late despite a clean start. This is exactly the class of visibility that SSV improved with qbft-instance: log stage durations.

Relation to SSV

This is the closest Anchor equivalent to SSV's shipped QBFT stage-duration logging and its still-open timeout-alignment work (Dynamic QBFT Timeout, Round change according to duty start time).

Scope

Instrument the proposer QBFT path with events and low-cardinality metrics covering at least:

• instance spawn / initialization
• effective instance start time
• proposal receipt
• round timeout
• round advancement
• decision
• decision round
• aggregated commit availability if applicable

The instrumentation should preserve current behavior. This is observability work, not timeout logic work.

Out of Scope

• changing TimeoutMode
• changing round-timeout formulas
• leader-selection changes
• closing #758 through behavior changes

Acceptance Criteria

• proposer duties record the round on which they decided or timed out
• round timeout and round-advance events are visible per proposer duty
• we can distinguish late start from round churn using the new data
• the PR does not alter current consensus semantics

References

• QBFT: PROPOSER round timeout uses slot-based timing instead of relative timing #758
• qbft-instance: log stage durations
• Dynamic QBFT Timeout
• Round change according to duty start time

[jnhsigmap]

Opened #1066 and #1067 to split into multiple PRs