fix(dp): requeue volume populator wait states

[weicao]

Summary

This is a stacked follow-up on PR #10447.

It fixes two generic VolumePopulator retry/requeue gaps found during etcd restore validation:

• return conflict errors from handleSyncPVCError even when the target PVC already has the Populating condition, so controller-runtime can retry stale status/resource-version updates
• actively requeue Populate() while prepareData jobs are not finished, so the controller does not depend on a later external PVC event after the restore container has exited and the restore-manager sidecar is still running

It also carries two changes beyond the retry/requeue scope (called out explicitly for review):

• decidePVCRestore: when no volume-level restore exists and the full target selector rejected the PVC (pod-only labels), clear skipPostReady if the PVC's component matches the target's component selector, so the target component's PVCs still drive postReady for logical backups. Note the overlap with fix: match backup targets to restore PVC labels #10354, which fixes the selector matching itself — once fix: match backup targets to restore PVC labels #10354 merges, this fallback should become a no-op for the logical-backup case and can be re-evaluated.
• patchInternalRestoreStatus / patchInternalRestoreMetaAndStatus: re-read the latest Restore and apply only the fields this reconcile intended to change (original→desired delta onto latest), instead of merge-patching from a possibly stale base, to avoid clobbering concurrent Restore status writers.

Validation

Focused unit tests:

go test ./controllers/dataprotection -run 'TestPopulateRequeuesWhenRestoreContainerFinishedBeforeJobComplete|TestHandleSyncPVCError(RequeuesConflictWhenPVCIsPopulating|KeepsInternalRequeueWhenPVCIsPopulating)|TestPatchInternalRestoreStatusUsesLatestRestoreResourceVersion' -count=1

Runtime validation on stacked head 943044aed667a71c2848da47c7b103920d6f6245:

• scope: idc4 node4 single-node vcluster, KB 1.2.0-alpha.2, local-sideload DP image
• image: kubeblocks-dataprotection:pr-10447-943044aed-20260626
• image identity: sha256:6744bc202b83d4e4314534adeb9a178307090334f0f00ddf1aef5538860fbf65
• result: Gate 4 v3 accepted scoped PASS
• restore: fully automatic, no manual PVC patch, total restore time 41s, prepareData completed in 13s
• readback: 3/3 etcd keys, revision=4
• evidence: build 9/9, import 3/3, runtime 11/11, cleanup 26/26 SHA checks OK

Scope boundary

The runtime PASS above was run on the stacked combined head 943044aed, not on PR #10447 head alone.
PR #10447 should remain the original restoreData/skipPostReady selector fix; this PR carries the follow-up generic VolumePopulator retry/requeue fixes.

[codecov]

Codecov Report

❌ Patch coverage is 74.11765% with 22 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.05%. Comparing base (4933980) to head (943044a).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
...llers/dataprotection/volumepopulator_controller.go	74.11%	15 Missing and 7 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10458      +/-   ##
==========================================
+ Coverage   62.04%   62.05%   +0.01%     
==========================================
  Files         533      533              
  Lines       63625    63707      +82     
==========================================
+ Hits        39473    39535      +62     
- Misses      20550    20565      +15     
- Partials     3602     3607       +5     

Flag	Coverage Δ
unittests	62.05% <74.11%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[weicao]

Self-review outcome: the core change here is still the 1s requeue polling that was explicitly rejected twice on this same wait state (#10477, #10481 — the direction given was event-driven Pod watch + Job/PVC label mapping), and the by-design question raised by @wangyelei on #10477 (stop-restore-manager=true is only set after all restore job containers complete) has not been answered with new evidence. This PR also bundles four changes; per the one-owner-investigation direction given when #10481 was closed, this should not stay open as-is. The one independently valuable piece is the conflict-requeue fix in handleSyncPVCError (the current code swallows conflicts for PVCs that already carry a Populating condition and returns Reconciled) — that can be extracted into a narrow PR with its own reproduction. Recommending close + extract.

[weicao]

Closing per the analysis above: the polling approach was rejected twice on this wait state (#10477/#10481) and the by-design question remains unanswered. The conflict-requeue piece of handleSyncPVCError will be extracted into a narrow PR with its own reproduction if it holds up independently.