task(nvca): persist workload config after Helm updates

[sbaum1994]

Task

Persist the workload configuration rendered for a successful MiniService Helm update so subsequent status reconciles use the configuration associated with the newly applied workload revision.

Current behavior

The initial-install path decodes the nvcf-workload-config control ConfigMap and calls saveWorkloadConfig with the decoded value.

The Helm-update path does not propagate that value:

workloadObjs, resources, _, err := decodeObjects(ctx, r.Decoder, objsData)

prepareUpdateWorkload discards the third return value, and doUpdateWorkload never persists an updated workload config. As a result, a successful Helm revision can apply new workload objects while MiniService.spec.workloadConfig continues to describe the prior revision.

Impact

• Enabling StatusByWorkerReadiness in a later Helm revision does not enable worker-readiness status behavior.
• Disabling the flag or removing nvcf-workload-config can leave the prior behavior active indefinitely.
• The applied workload and the configuration used by MiniService status reconciliation can diverge.

Required behavior

1. Carry the decoded WorkloadConfig through the workload-update preparation path.
2. After the workload revision is applied successfully, persist the corresponding config through saveWorkloadConfig before completing the update.
3. Treat an absent control ConfigMap as an absent workload config, clearing the previously controller-owned field.
4. If rendering, validation, or workload application fails, retain the workload config for the previously active revision so status behavior remains aligned with the workload that is still serving.
5. Preserve the targeted SSA ownership contract introduced by fix(nvca): preserve MiniService spec when saving workload config #626: miniservice-controller owns only spec.workloadConfig, and unrelated MiniService spec fields remain untouched.

Acceptance criteria

• A successful Helm update from no config to StatusByWorkerReadiness: true persists the enabled flag.
• A successful update from enabled to disabled persists false.
• A successful update that removes nvcf-workload-config clears spec.workloadConfig.
• A failed workload update leaves the previously persisted config unchanged.
• Regression tests cover successful replacement, removal, and failed-update sequencing.
• Existing namespace, request-name, Helm configuration, metadata, and status fields are not modified by workload-config persistence.

Relationships

• Follow-up to NVCA workload config persistence prunes required MiniService spec fields #625, which covers the initial-install persistence failure.
• fix(nvca): preserve MiniService spec when saving workload config #626 fixes compatibility serialization and uses a serializer-independent targeted SSA payload for spec.workloadConfig.