Solo: suppress NEW_ROUND recovery GET_BLOCK at timer fire when PUSH is in transit

[Copilot]

The "Cancelling pending NEW_ROUND recovery GET_BLOCK" log was firing but the deferred GET_BLOCK still went out, producing duplicate BLOCK_DATA that only the miner-side 10s same-unified-height feed guard was eating. Root cause: when a PUSH arrives within ~1ms of timer expiry, asio::steady_timer::cancel() returns 0 because the wait is already queued on the io_context — the cancel log fires from elsewhere, but the queued callback still runs and sends.

Change

• Solo::schedule_recovery_get_block (src/protocol/src/protocol/solo.cpp): capture unified_height in the async_wait lambda and re-evaluate push_implies_block_data_in_transit(snap, unified_height, push_in_transit_guard_for_channel()) immediately before the GET_BLOCK send, after the existing has_valid_template short-circuit. If a PUSH ≥ unified_height landed within the channel-aware in-transit window (Prime 6000ms / Hash 3000ms), clear m_recovery_deferred_at, log [NEW_ROUND] Recovery GET_BLOCK suppressed at fire time: ..., and return.

Scope

• Confined to the NEW_ROUND deferred-recovery path. PUSH-response, BLOCK_ACCEPTED/REJECTED, health-monitor, startup, and worker_manager recovery GET_BLOCK paths are untouched.
• No constants tuning (handled in Tune NEW_ROUND recovery debounce and GET_ROUND polling cadence to reduce duplicate template churn #704).
• Reuses the same in-transit predicate already applied at scheduling time (Phase C1) and at the other GET_ROUND / BLOCK_AVAILABLE call sites, so behavior is consistent across the three guard tiers (schedule-time, cancel-on-PUSH, fire-time).