Server-side apply on an application drops its HelmRelease finalizer, so deleting it orphans the release #4482

Server-side apply on any apps.cozystack.io application strips the Flux finalizer from its HelmRelease, and deleting the application afterwards leaves the Helm release and everything it created behind. helm-controller does not put the finalizer back on its own, so this is not a race: after one apply, every later delete of that application orphans its release.

Reproduced on a fresh cluster with a Tenant, which makes the leftover easy to see:

kubectl apply --filename tenant-qa.yaml                                   # Tenant qa in tenant-root
kubectl --namespace tenant-root get hr tenant-qa -o jsonpath='{.metadata.finalizers}'
# ["finalizers.fluxcd.io"]
kubectl apply --server-side --field-manager=probe --force-conflicts --filename tenant-qa.yaml
kubectl --namespace tenant-root get hr tenant-qa -o jsonpath='{.metadata.finalizers}'
# (empty, and still empty minutes later)
kubectl --namespace tenant-root delete tenants.apps.cozystack.io qa
kubectl --namespace tenant-root get secret -l owner=helm,name=tenant-qa   # release still "deployed"
kubectl get namespace tenant-qa                                            # still Active

A merge patch through the same API keeps the finalizer; only apply loses it. The same thing happens through the in-process apiserver with a fake client on both the current main and the Kubernetes 1.37 branch (#4473), so it is not new.

REST.Update rebuilds the HelmRelease from the Application and copies back only the shard label and spec.suspend from the live object (rest.go#L619). metadata.finalizers is not among them, so whatever the incoming Application carries wins, and an applied Application carries none. Keeping the live HelmRelease's finalizers the same way would fix it. A test that applies an application whose HelmRelease has a finalizer and expects the finalizer to survive would pin it.

To clean up an orphan: helm --namespace tenant-root uninstall <release>.