Optimize validator sync and other minor changes

[SpyCheese]

No description provided.

[github-actions]

validator/manager.cpp:604: This early return also skips the validating_masterchain() block below. When the shard client is absent or more than 60s stale, a masterchain validator will no longer run preload_msg_queue_to_masterchain(), wait_verify_shard_blocks(), or mark ready_desc, so collators can miss valid shard block descriptions via get_shard_blocks_for_collator(). If the intent is only to avoid wait_block_state_short() while out of sync, gate just the need_monitor(...)/nonfinal-state path and still allow the masterchain validation preparation to run.

[github-actions]

• validator/manager.cpp:663: latest_desc is stored before the out-of-sync early return, but the only path that can populate ready_desc is below that return. If a masterchain validator receives a shard block description while shard_client_handle_ is stale, that description remains in shard_blocks_ as latest but never gets verified/preloaded later; duplicate/newer-or-equal descriptions are then dropped at lines 658-661, and collators only consume ready_desc. Move the sync guard before updating latest_desc, or schedule/retry readiness processing after shard-client catch-up.

[github-actions]

• validator/manager.cpp:665 This early return skips the validating_masterchain() path below, so a masterchain validator that is temporarily shard-client-lagged records latest_desc but never preloads/verifies the shard block description or calls set_shard_block_description_ready. Since update_shard_blocks() does not retry that work when the shard client catches up, valid shard descriptions received during lag can remain unusable for collation until a newer broadcast arrives. Move the out-of-sync guard so it only skips the nonfinal lite-server wait_block_state_short work, not the masterchain-validator readiness path.