Summary

Removes the redundant single-shot Go ClusterPolicy readiness check from the deployment-phase expected-resources validator. The registry-declared chainsaw gpu-operator health check already asserts the same ClusterPolicy state: ready with a polling timeout, so the Go check added nothing but flake.

Motivation / Context

The UAT - AWS run failed the expected-resources gate it gates on, with a single failure: [INTERNAL] ClusterPolicy state=notReady (want ready). Investigation showed the GPU Operator readiness signal was being checked two ways inside the same validator:

• verifyClusterPolicyReady (Go) read ClusterPolicy.status.state once, with no retry — it sampled ~13s into the run.
• The chainsaw gpu-operator health check (recipes/checks/gpu-operator/health-check.yaml, step validate-cluster-policy-ready) asserts the same state: ready but polls up to 5m.

On a fresh node the nvidia-operator-validator runs four sequential init containers (driver → toolkit → cuda → plugin) before ClusterPolicy reconciles to ready — ~2.5m in the failing run. The Go check fired far too early and flaked the whole deployment gate, while the chainsaw check waited and passed. (Nodewright tuning was already complete and the DRA kubelet-plugin healthy, so neither was the cause.)

This completes the clusterPolicyReady migration that was deferred in #1220 / #1235 (the chainsaw replacement landed but the Go original was never removed).

Fixes: N/A
Related: #1220, #1235

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• Build/CI/tooling

Component(s) Affected

• Validator (pkg/validator)

Implementation Notes

• Removed verifyClusterPolicyReady, its call site in verifyGPUReadinessSignals, and the now-unused gpuOperatorComponent / clusterPolicyName / clusterPolicyReadyState consts and clusterPolicyGVR var.
• The chainsaw assert is co-extensive with the removed Go check (both fire only when gpu-operator is enabled) and strictly superior (polls instead of single-shot), so there is no coverage loss.
• verifyNodewrightReady and verifyDRAKubeletPluginReady deliberately stay in Go — their resource names are dynamically/release-derived and cannot be expressed in static chainsaw YAML. Neither was implicated in this flake.
• Fail-closed-on-discovery-error coverage is preserved by re-targeting TestCheckExpectedResources_FailsWhenDiscoveryReturnsNonNotFoundError at the Nodewright discovery gate, which shares the same pattern.

Testing

go build ./validators/...
go test ./validators/...                                  # all packages pass
golangci-lint run -c .golangci.yaml ./validators/deployment/...   # 0 issues (pinned v2.12.2)

• go test ./validators/... — all packages pass (deployment, chainsaw, conformance, helper, performance).
• Lint clean with the repo-pinned golangci-lint v2.12.2.
• Note: -race could not be exercised in my environment (no C compiler); CI's make qualify will run the race detector.

Risk Assessment

• Low — Isolated change, well-tested, easy to revert

Rollout notes: No behavior change for healthy clusters — the deeper ClusterPolicy state: ready signal is still asserted via the chainsaw gpu-operator health check, now with correct polling semantics. The only residual consideration: the chainsaw assert's 5m poll must cover ClusterPolicy reconcile on a fresh node (observed ~2.5m); a genuinely slower reconcile would now fail legitimately rather than flakily.

Checklist

• Tests pass locally (make test with -race)
• Linter passes (make lint)
• I did not skip/disable tests to make CI green
• I added/updated tests for new functionality
• I updated docs if user-facing behavior changed
• Changes follow existing patterns in the codebase
• Commits are cryptographically signed (git commit -S)