Warning: This build has drifted.
The coverage report for this pull request build may be inaccurate because its base commit is no longer the HEAD of its target branch.
This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

    • Learn more: For more information on this, see Tracking coverage changes for pull request builds.
    • Fix now: For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
    • Prevent going forward: To avoid this issue with future PRs, see these Recommended CI Configurations.

planner: two-step model with proportional slack + per-revision aliveness

Fix two related planner issues surfaced by scenario 02 (5P/2D, surge=1
unavail=1) and scenario 01 (20P/4D, surge=3 unavail=2):

- Scenario 02 violated maxUnavailable because the small role (decode)
  reached spec=0 while the large role (prefill) still had replicas to
  drain — old revision left half-serving; executor's coordinated drain
  then over-wiped prefill.
- Scenario 01 became too slow after tightening semantics: with
  totalSteps = max(role sizes), per-tick wantNew grew by 1 pod even
  though the surge budget allowed 3 in-flight.

Planner changes (planner.go):
- sideSize = max(role sizes): fine granularity (1 minUnit = 1 pod of
  the largest role); smaller roles absorb ticks via ceil-rounding.
- wantReplicas uses ceil on both sides: aliveness invariant — a small
  role holds at ≥1 while others are still draining, both reach 0 at
  the final tick.
- projectBudget: MaxSurge / MaxUnavailable become minUnit multipliers
  projected per-role by size ratio (largest role gets full multiplier,
  smaller roles get proportional slack).
- Two-step model: progressStep (+1/tick, baseline) drives completion
  detection; specTargetStep (= progressStep + surge for NEW / + unavail
  for OLD) drives wantNew/wantOld so each tick consumes the full
  surge/unavail budget in one round-trip.
- Planner-level aliveness cap: when one role is drain-budget-blocked
  while another actually drains, hold both to keep old-side roles in
  step. Next tick, addNew grows total → drainBudget grows → blocked
  role catches up.

Executor changes (executor.go):
- scaleUpNew ceiling uses proportional projection (was raw MaxSurge).
- isRevisionStable tolerance projected per-role (was raw surge+unavail).
- scaleDownOld: replaced coordinated-drain with per-revision aliveness
  guard — retire whole revision when planned drain would orphan AND
  budget allows; otherwise skip the orphaning drains.
- Deadlock fallback:... (continued)