Fix OneCycle initial momentum: use cycle_max_mom, not cycle_min_mom - #8979

Bug

OneCycle._initialize_momentum() sets the optimizer's initial beta1 to cycle_min_mom, but the inverse-cycling schedule starts at cycle_max_mom (at scale_factor=0, get_mom() returns max_mom - 0 = max_mom). This means the first optimizer.step() consumes a different momentum than the schedule intends, causing a training-correctness divergence from the second update onward.

Fixes #8951

Root cause

# Before (line 576):
for momentum, group in zip(self.min_moms, optimizer.param_groups):
    group['betas'] = momentum

# After:
for momentum, group in zip(self.max_moms, optimizer.param_groups):
    group['betas'] = momentum

The LR/momentum symmetry: LR initialises at min and ramps up; momentum initialises at max and ramps down. _initialize_lr correctly sets min_lrs; _initialize_momentum was incorrectly mirroring that instead of inverting.

Changes

1. deepspeed/runtime/lr_schedules.py: Initialise optimizer betas from self.max_moms instead of self.min_moms
2. Docstring: Remove "Initial momentum" wording from cycle_min_mom param (it's the lower bound, not the initial value)
3. tests/unit/runtime/test_lr_schedulers.py: Fix test_one_cycle_accepts_per_group_lr_and_momentum_lists which asserted the wrong initial betas, and add test_one_cycle_initial_optimizer_momentum_matches_schedule verifying optimizer state matches the scheduler's reported momentum at construction