fix: use StrategicMergePatchType for pod condition updates to avoid TOCTOU race

[WorrierKhushal]

What type of PR is this?

/kind bug

What this PR does / why we need it:

Background

The PullPodImage handler in pkg/yurthub/otaupdate/ota.go injects a
PodImageReady condition onto a Pod during OTA image pull. It fetched the
current Pod, locally mutated the full Status.Conditions array via
podutil.UpdatePodCondition, and patched the Pod with the entire array
using types.MergePatchType.

The Bug

MergePatchType (RFC 7386 JSON Merge Patch) does not support array
merging — it replaces arrays wholesale. If the Kubelet or another
controller updated a Pod condition (e.g. Ready=True) in the window
between this handler's getPod() call and its Patch() call, that
update was silently overwritten by the stale array this handler had
fetched earlier. This could leave a Pod stuck reporting as not-ready on
the control plane even after the Kubelet had confirmed it was running.

Verification of the fix approach

Checked k8s.io/api v0.34.0's PodStatus.Conditions field definition
directly — it carries patchStrategy:"merge" patchMergeKey:"type",
confirming the API server natively supports a strategic merge patch that
merges condition entries by their Type field. Also confirmed the fake
clientset used in this package's tests fully supports
StrategicMergePatchType.

The Fix

• Removed the local podutil.UpdatePodCondition full-array mutation
  (and the now-unused podutil import).
• Changed the patch payload to contain only the single new condition
  instead of the full conditions array.
• Changed the patch type from types.MergePatchType to
  types.StrategicMergePatchType, letting the API server perform the
  merge natively by condition Type, eliminating the TOCTOU window
  entirely.

Added TestPullPodImageStrategicMergePatch, verifying the patch sent is
StrategicMergePatchType and contains exactly one condition.

Which issue(s) this PR fixes:

Fixes #2754

Special notes for your reviewer:

• go test -v ./pkg/yurthub/otaupdate/... — all tests pass (verified on Linux/WSL), including the new test
• go build/go vet on the affected package — clean
• No exported function signatures changed; scoped entirely to the patch construction inside PullPodImage

Does this PR introduce a user-facing change?

NONE

other Note

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud