[thxCode]

What type of PR is this?

/kind cleanup
/area worker

What this PR does / why we need it:

Workload rendering, admission and native observation each carried their own copy of the elastic collective's supported width range. Three copies are three answers, and they drift in the direction nobody reads: widening admission alone leaves native observation refusing a width the deployment is already allowed to ask for.

pkg/worker/elasticprofile now declares the range once and all three consumers read it from there:

• model_deployment_elastic_workload.go — the inline width < 2 || width > 64 literals are gone.
• webhooks/worker/model_deployment_elastic.go — the local modelDeploymentElasticWidthMin/Max pair is gone.
• elasticengine/effective_observation.go — maxObservedWorldWidth is now elasticprofile.WidthMax.

The profile is not widened. These are the values the three consumers already enforced.

Each consumer gains a contract test that asks the shared constants for the boundary widths and checks its own behaviour, so a bound restated inside a consumer fails the check:

Test	What it holds
TestProfileWidthBounds	the declared pair is 2 and 64
TestValidateModelDeploymentElasticEPWidthBounds	admission admits both edges, refuses one outside each
TestModelDeploymentElasticBootstrapFromMasterWidthBounds	rendering retains both edges, holds one outside each, for a new and a live master
TestObserveNativeWorldElasticProfileWidths	native observation measures every width from 2 to 64 and refuses WidthMax+1 and 0 before sending a request
TestObserveNativeWorldProbeFloorIsNotTheProfileFloor	the observer's own floor stays at 1 and never rises above the profile's

One disagreement with the issue, reported rather than resolved silently. #716 says the three
consumers "currently agree on widths 2 through 64". They did not quite: ObserveNativeWorld
enforced a floor of 1, not 2. That floor is a probe budget rather than a profile claim — a
single-rank world is a real world, and refusing to measure it would say nothing true about it.
Narrowing it would be a behaviour change on a public path, so it was left alone and made explicit
instead. The ceiling — the bound that actually couples the two — is the shared one.

RED proof. Giving one consumer its own bound copy (the webhook's pair restored as local
constants with a widened maximum of 128) fails the check, naming the exact width that diverged:

--- FAIL: TestValidateModelDeploymentElasticEPWidthBounds/one_above_the_profile
    width 65 refused=false, want refused=true (errors: [])
RED RUN EXIT: 1

Reverting restores the shared implementation and the check goes green (GREEN RUN EXIT: 0).

Known residual. api/worker/v1alpha1/model_deployment.go carries the same pair as kubebuilder
markers on ModelDeploymentRoleElasticEP.Width (+k8s:validation:minimum=2,
+k8s:validation:maximum=64). That is a fourth declaration, outside this change's scope. It is
not a live hazard — it constrains the API server's schema, and the webhook below it would still
refuse an out-of-range width, so the failure direction stays fail-closed.

Which issue(s) this PR links to:

Fixes #716

Special notes for your reviewer:

The two changes do not overlap: #715 touches the allocation and router-observation paths, this one
touches rendering, admission and the engine client, so they are two PRs rather than one.

Verification: go build ./... and go test ./pkg/worker/... -count=1 both exit 0 on this branch
alone. make lint could not complete on this host — the Go stage is clean (golangci-lint reports
0 issues) but the unrelated .agents shell self-test cannot clean up its temp directory under this
runtime's deletion interception, which reproduces on a pristine tree too.

Does this PR introduce a user-facing change?

NONE

[gpustack-code-review]

🔍 OpenCodeReview found 1 issue(s) in this PR.

• ✅ Successfully posted inline: 0 comment(s)
• 📋 Routed to summary by policy: 1 comment(s)

---

📄 pkg/worker/webhooks/worker/model_deployment_elastic.go (L157-L157)

⚠️ GitHub could not post this as an inline comment: Routed to summary (severity low · category test)

Reminder (not a claim about this PR): webhook source changes must be accompanied by the regenerated output (make generate → zz_generated.webhooks.go), which is excluded from this review — please confirm it was regenerated if the generated surface is affected. This is a pure constant-source swap (same 2–64 values), so no behavioral drift is expected; a regression test reminder applies only if a bug fix is introduced later.