Helm post-delete hook deletes systemNamespace and karmada-cluster on the host cluster, but they only get created in the karmada-apiserver

**What happened:** The Helm chart applies and deletes the `systemNamespace` / `karmada-cluster` Namespace objects against two different clusters. On install they get applied to the karmada control plane (karmada-apiserver) using `--kubeconfig /etc/kubeconfig`, in `karmada-static-resource-job.yaml`: ```sh kubectl apply -f /static-resources/system-namespace.yaml --kubeconfig /etc/kubeconfig kubectl apply -f /static-resources/ --kubeconfig /etc/kubeconfig ``` But on uninstall, the post-delete hook (post-delete-job.yaml) deletes those same manifests against the host cluster. There's no --kubeconfig, so it uses the in-cluster service account: ```sh kubectl delete -f /opt/static-resources/ --ignore-not-found=true -R ``` /opt/static-resources/ includes system-namespace.yaml, which has Namespace/<systemNamespace> and Namespace/karmada-cluster in it. kubectl delete -f matches a Namespace by name, so this deletes those namespaces off the host cluster, which is a cluster the chart never created them on in the first place. Since deleting a namespace cascades, it takes everything inside that host namespace with it. **What you expected to happen:** The post-delete hook shouldn't run kubectl delete -f on cluster-scoped Namespace objects against the host cluster. Pointing the hook back at the karmada-apiserver isn't really an option since the control plane is already gone by the time post-delete runs, so I think the fix is to leave the Namespace manifests (system-namespace.yaml) out of the host-side delete -f and only delete the host resources the chart actually owns. **How to reproduce it (as minimally and precisely as possible):** 1. Install the chart into namespace A (--namespace A). 2. Set systemNamespace: B (something other than A). 3. On the host cluster, create namespace B yourself (or have one already there). 4. Run helm uninstall. 5. Namespace B gets deleted on the host, along with whatever was in it. **Anything else we need to know?:** This isn't just an edge case from my config. With the defaults (systemNamespace: karmada-system) plus a pretty common --namespace karmada-system install, the post-delete hook ends up targeting karmada-system on the host, which is the release namespace itself. Not sure if deleting the release namespace on uninstall is intentional. **Environment:** - Karmada version: chart v1.18.0 - kubectl-karmada or karmadactl version (the result of kubectl-karmada version or karmadactl version): n/a (installed via the Helm chart, not karmadactl) - Others: Helm v4.1.3, installMode host