[huskcass]

What type of PR is this?

• bug fix

What this PR does and why

The Scaling card (ReleaseObjects.tsx) and the scaler step in both install-status views (inferences/lib.ts, swiss/routes/DeploymentDetail.tsx) marked a scaler as failing if any of its conditions was False. ScalingDeferred=False with reason NotDeferred is the normal state, so every healthy scaler showed NotDeferred as a warning or a bad step.

modelsphere/llm-operator#23 adds a summary Ready condition, status.observedGeneration and status.lastScaleTime, in the style of HPA v2 and KEDA. It also replaces ScalingDeferred with an HPA-style AbleToScale condition, where True is normal: Synced, a hold reason (RolloutInProgress, ScaleDownSettling) or DeferralTimedOut. False means the target cannot be scaled (InvalidSpec, TargetNotFound, TargetUnreadable, TargetWriteFailed).

All three places now go through one helper, scalerHealth in web/src/modules/swiss/lib/scaler.ts:

Operator	Failing	Waiting	Otherwise
has Ready / AbleToScale	Ready=False or AbleToScale=False, shown with its reason (Ready first)	AbleToScale=True with RolloutInProgress or ScaleDownSettling: deferred: <reason>	current/desired comparison, as before
older, ScalingDeferred	only DecisionAvailable=False	ScalingDeferred=True: deferred: <reason>	current/desired comparison, as before

ScalingDeferred=False (NotDeferred, DeferralTimedOut) from older operators is never treated as a failure. When AbleToScale is present, a leftover ScalingDeferred is ignored.

Also:

• LLMScalerStatus gains appliedReplicas, observedGeneration, lastScaleTime and deferredSince.
• The Scaling card shows a "Last scaled" fact when lastScaleTime is set. It also shows the stale-generation note from observedGeneration, the same note the route panel uses.
• New i18n key scaler.deferred in en-US and zh-CN.

Which issue(s) this PR fixes

Refs modelsphere/llm-operator#23

How it was tested

• scaler.test.ts: table-driven scalerHealth cases covering AbleToScale (each hold reason, Synced, DeferralTimedOut, False, precedence against Ready) and older operators with ScalingDeferred, including NotDeferred reading as ok.
• lib.test.ts: installSteps with NotDeferred is steady, Ready=False is bad, and ScalingDeferred=True is waiting.

Checks

• npm run typecheck && npm test && npm run build in web/ (48 files, 437 tests)
• No internal hostnames, IPs, registries or credentials

Release note

The Scaling card and install status no longer show a healthy LLMScaler's NotDeferred condition as a failure. They use the operator's Ready and AbleToScale conditions when present, and fall back to DecisionAvailable and ScalingDeferred for older operators.