Bug and impact

When some beam-search candidates reached EOS before max_tokens while other active beams were still valid, the backend discarded all remaining active beams because completed was non-empty. The cache then contained fewer responses than the requested beam width, so later beam indices repeated the same completed candidate and effective beam width collapsed for constrained/two-stage rollout evaluation and training.

Root cause

The recent duplicate-avoidance logic only preserved active beams when no candidate had completed at all, instead of preserving active beams whenever completed candidates did not fill beam_width.

Fix

Fill the remaining beam slots with active length-finished beams until beam_width is reached, while still avoiding active-beam duplicates once completed beams already cover the requested width.

Validation

• Added regression coverage for a beam search where one candidate completes with EOS early and another remains active until max_tokens.
• Ran a direct Python regression scenario for the new case.
• Ran python3 -m py_compile verl_gr/workers/rollout/beam_backend.py tests/test_minionerec_parity.py.

Note: python3 -m pytest tests/test_minionerec_parity.py could not run in this environment because pytest is not installed.