[v0.15] fix(agent): apply pod-security labels from namespaceLabels again

[p-se]

namespaceLabels in fleet.yaml exists so that a bundle can label the namespace it deploys into, and setting Pod Security Admission labels that way is what SURE-5906 (#1484) asked for. Since #5156 the agent dropped every pod-security.kubernetes.io/ key from the options and skipped those keys when pruning, so labels a user declares are silently ignored (SURE-11931, #5550).

That filter was the fix for GHSA-864g-863m-vcvq, where a bundle could weaken PSA enforcement on its target namespace because the agent applied namespaceLabels with its own cluster-admin credentials. #5351 changed that: the namespace is patched as the deployment's service account, so downstream RBAC decides what a bundle may write to it, and the prefix filter is no longer the control it was.

The filter never covered the whole path either. The same label reaches the same API call, under the same credentials, when it is declared on a Namespace object in the bundle, or when a pre-provisioned namespace is adopted with helm.takeOwnership. It also matched on the key alone, so it refused tightening enforcement, and setting warn or audit levels, just as it refused weakening.

Pod-security labels are therefore treated like every other namespace label again: applied when declared, pruned when they are not. Dropping the pruning exemption as well keeps un-setting working, which that exemption broke for these keys specifically.

Deployments that resolve to no service account still patch the namespace as the agent, which is cluster admin. Restricting those requires pinning a service account, in the bundle or through a Policy.

Refers to #5702

(cherry picked from commit 51c99ee)

Additional Information

Checklist

• I have updated the documentation via a pull request in the fleet-product-docs repository.