gap-ratio: gate demand inflation to the bootstrap window

[TianyeGGBond]

Context

Fixes #36 (S12-INFLATE-WINDOW from the F1-F12 scheduler review).

In plan_generation_gap_ratio, the demand-inflation branch:

if has_pending:
    # Inflate demand in the bootstrap window (request sent, no progress yet)
    remaining += step_target

was meant to fire only during the bootstrap window ("request sent, no
progress yet"). But its condition only checks rollout_open_pipelines
membership, and that entry survives until release / clear_progress. So
while a rollout is actively progressing (step_target > 0), the branch
still fires and demand is double-counted (remaining = actual_remaining + step_target, percent_remaining > 1), skewing gap-ratio toward whichever
pipeline happens to hold an entry when the other doesn't.

Not a hang — allocation-fairness drift.

Change

scheduler/planner.py:

• Capture in_bootstrap_window = step_target <= 0.0 before the estimate
  branch overwrites step_target.
• Gate the inflation on has_pending and in_bootstrap_window so it only
  applies when no progress has been reported yet.

The bootstrap path is byte-for-byte unchanged; only the erroneous
firing on an actively-progressing rollout is removed.

Net: +5 / -3 lines.

🤖 Generated with Claude Code

[JunzheJoe]

Verified against the semantics confirmed in #36 — capture-before-overwrite is correct, bootstrap path unchanged, double-count on actively-progressing rollouts removed. LGTM (filed the original finding as S12-INFLATE-WINDOW in the F1-F12 review).

[teddytennant]

This gate starves a pipeline whose progress reports are already complete but which has just enqueued a new generation request. With progress = (remaining=0.0, step_target=100.0) and a pending request, in_bootstrap_window is false, so remaining stays 0, target_ratio is 0, gap is 0, and the activation loop never picks it. It gets zero GPUs. The max(rounded_bundles * tp_size, tp_size) floor at planner.py:288 doesn't rescue it, because the gap is already 0 before the floor applies.

That state is reachable: _derive_remaining_from_report at scheduler.py:826 clamps to max(step_target - completed, 0), so a finished-but-uncleared rollout gives remaining == 0 with step_target > 0.

Gating on remaining <= 0.0 instead fixes the case you're fixing and keeps that one alive. Unless the coordinator always calls clear_progress before enqueueing the next generation request, in which case the state never occurs and this gate is fine as written. Do you know which it is? I couldn't tell from reading it.