fix(operations): two-pass reconfigure validation to prevent partial CP pollution

[weicao]

Summary

• Separate Action() into validate-all then apply-all (two-pass) so that an invalid parameter in a later Reconfigure entry cannot leave dirty ComponentParameter.spec.desired from an earlier entry.
• For sharding, resolve each shard's actual ComponentDefinition via ListShardingComponents for schema validation, instead of using only the sharding template default.
• Add three new test cases covering: single invalid parameter rejection, multi-entry first-valid/second-invalid no-dirty-CP invariant, and sharding with distinct template vs actual CompDef regression guard.

Problem

The original PR #10415 had two P1 issues identified by @leon-ape:

1. Validation and patching were interleaved in a single loop — if entry[0] patched CP desired and entry[1] failed validation, entry[0]'s dirty write remained.
2. Sharding validation only checked the template default ComponentDefinition, missing heterogeneous shard CompDefs.

Solution

Pass 1 iterates all Reconfigure entries and calls validateReconfigureParameters() which resolves the actual ComponentDefinition(s), loads their ParametersDefinition JSON schema, and validates parameter assignments. Any failure returns a fatal error immediately — no CP is touched.

Pass 2 only runs after all validations pass, applying patches via applyReconfigureToParameters().

For sharding, resolveCompDefNames() calls sharding.ListShardingComponents() to get the real Component objects and their Spec.CompDef, collecting unique CompDef names for validation.

Test plan

• rejects unknown parameter before patching CP desired — single invalid param rejected, CP desired clean
• multi-entry: invalid second entry blocks valid first entry from patching CP — two components, first valid + second invalid, neither CP patched
• sharding: validates against actual shard ComponentDefinition, not template default — template CompDef has no schema, actual shard CompDef has strict schema; only the ListShardingComponents path rejects unknown_param
• Existing Test Reconfigure OpsRequest and propagates ComponentParameter merge failure still pass
• go build, go vet, git diff --check clean
• Jade peer review: no design-contract blocker

Supersedes #10415 (addresses P1 review comments).

[apecloud-bot]

Auto Cherry-pick Instructions

Usage:
  - /nopick: Not auto cherry-pick when PR merged.
  - /pick: release-x.x [release-x.x]: Auto cherry-pick to the specified branch when PR merged.

Example:
  - /nopick
  - /pick release-1.1

CLA Recheck Instructions

Usage:
  - /recheck-cla: Trigger a re-check of CLA status for this pull request.
Example:
  - /recheck-cla

[codecov]

Codecov Report

❌ Patch coverage is 62.50000% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.02%. Comparing base (4933980) to head (afc0684).

Files with missing lines	Patch %	Lines
pkg/operations/reconfigure.go	62.50%	12 Missing and 6 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10438      +/-   ##
==========================================
- Coverage   62.04%   62.02%   -0.02%     
==========================================
  Files         533      533              
  Lines       63625    63673      +48     
==========================================
+ Hits        39473    39493      +20     
- Misses      20550    20579      +29     
+ Partials     3602     3601       -1     

Flag	Coverage Δ
unittests	62.02% <62.50%> (-0.02%)	⬇️

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.

[leon-ape]

This two-pass prevalidation needs stronger justification. Parameter schema validation belongs to the ComponentParameter/parameters controller path; Ops should trigger the desired update, not duplicate the schema validation responsibility. If the partial-write concern is about multiple entries targeting the same ComponentParameter, the safer fix is to coalesce those changes and patch that CP once. If the entries target different components, there has not been cross-component transaction semantics, so making one component invalid parameter block unrelated components adds a new all-or-nothing behavior that the API does not currently promise. Please keep schema validation in the parameters controller path, or explain the strong API-level reason for introducing this cross-component preflight semantics.

[weicao]

Closing per reviewer direction: parameter schema validation belongs to the ComponentParameter/parameters controller path, not the Ops reconfigure action. The Ops action should only trigger desired updates and let the parameters controller handle validation. This applies to both this PR and the original #10415.