Optimizer step based validation trigger

Nobody has claimed this yet.

### Description & Motivation

As far as I can see there are currently 2 modes to trigger the validation during training: 1) based on number of epochs (`check_val_every_n_epoch`) and 2) based on number of batches (`val_check_interval`)
Unfortunately we experience the case where another type is needed, based on (optimizer) steps.

1. `check_val_every_n_epoch` is not useful when the epoch size is too big.

2. `val_check_interval` could result in the training which is stuck when the number of batches seen across ranks goes out of sync which happens when the dataloaders on each rank have different number of microbatches. When `accumulate_grad_batches>1` one rank can exhaust all microbatches and even do a step using partial accumulation (as described in https://lightning.ai/forums/t/global-step-increased-at-new-epoch-regardless-of-gradient-accumulation/2480) while another rank advanced up until the optimizer step. Now the latter rank will start validation with a metric reduction at the end, while the former rank will iterate using a new dataloader batches until next optimizer. Now they stuck waiting for each other.

### Pitch

We can introduce a new option, e.g. `val_check_steps` that will make sure validation is triggered at optimizer step boundaries, after all ranks synchronize and hence all enter validation at the same time, reduce metrics at the end, and so on.

### Alternatives

Alternatively it should be possible, but clunky, to override `on_before_optimizer_step` and keep the count of `trainer.global_step` then when the module reminder is 0 set `trainer.val_check_batch` - potentially different for different ranks - so that on next `advance` all ranks enter validation.

Then again there could be a hard requirement in Lightning contract that requires that the number of batches is the same across all ranks (not sure if it's already required).

### Additional context

_No response_

cc @borda

Start by tracing the validation scheduling around val_check_interval and the optimizer-step entry point on_before_optimizer_step, including trainer.global_step and trainer.val_check_batch. Define how a val_check_steps option interacts with gradient accumulation and uneven dataloaders across ranks. Done means validation reliably starts at optimizer-step boundaries on all ranks, with coverage for synchronization and metric reduction behavior.

Written by the indexing model from the issue text.