ApplicationDefinition healthCheckExprs and waitStrategy never reach existing HelmReleases #4409

A change to healthCheckExprs or waitStrategy on an ApplicationDefinition never reaches the HelmReleases of applications that already exist. Only a new application, or an existing one written again through the apps API, gets it. So after an upgrade that changes these settings, old and new releases of the same kind wait on different things, for as long as nobody edits the old ones.

The apps API sets both fields when it builds a HelmRelease from an Application (pkg/registry/apps/application/rest.go:1724-1725 at eec069b). After that, the only thing that keeps existing releases in sync with their definition is ApplicationDefinitionHelmReconciler.updateHelmReleaseChart (internal/controller/applicationdefinition_helmreconciler.go:127-188 at the same commit). It copies chartRef, valuesFrom and the release labels, and nothing else: neither HealthCheckExprs nor WaitStrategy appears anywhere in that file.

Where it shows up today:

• postgres: packages/system/postgres-rd/cozyrds/postgres.yaml exempts the KEDA ScaledObject with current: "true". A postgres release created before that entry was added keeps waiting on the ScaledObject.
• vm-disk: fix(vm-disk): report DataVolume readiness through WorkloadsReady #4380 adds the same kind of entry for the CDI DataVolume, so an importing disk stops holding a helm-controller worker for the whole install timeout (a readiness gate on a user-sized operation holds one of the shard's five helm-controller slots for its whole run #4145). Disks that exist at upgrade time keep the wait, and the disk nobody edits is usually the stuck one this is meant for.

The same thing was noticed for the disable-wait annotation in #3734, where existing HelmReleases picked up the new spec only after their Application was written again.

I see two ways to fix it: copy both fields in updateHelmReleaseChart, the way chartRef is copied now, or regenerate a release's spec from its Application whenever the definition changes. The first is smaller. Its catch is that waitStrategy is derived through config.ResolveWaitStrategy, so the reconciler has to derive it the same way the apps API does.