fix(security): enforce CR reference authorization

[dc-tec]

Summary

Tighten CR author authorization for references and delegated dangerous controls.

This change makes OpenBaoCluster and OpenBaoRestore admission validate that the applying identity is authorized for referenced Kubernetes objects, cloud identity metadata, restore targets, custom executables, and Hardened image verification trust roots.

Key changes:

• Adds reusable reference authorization checks for CR fields that reference Secrets, PVCs, ServiceAccounts, Gateways, IngressClasses, StorageClasses, ServiceMonitor TLS objects, and image pull Secrets.
• Adds delegated usecloudidentities authorization for main workload, backup, and restore workload identity metadata.
• Adds delegated restore authorization for destructive OpenBaoRestore target selection.
• Keeps usehelperimages as a compatibility alias while documenting usecustomexecutables as the preferred verb.
• Adds aggregated/sample RBAC roles for cloud identity and restore delegation.
• Expands envtest, kustomize, Helm, provisioner, and E2E guardrail coverage.
• Updates RBAC, backup, restore, and production checklist docs so onboarding explains the new grants.

Related Issues

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor (code improvement/cleanup)
• CI, release, or build tooling
• Other maintenance

Risk and Compatibility

This intentionally tightens admission and RBAC behavior.

Existing clusters or GitOps pipelines that manage CRs with referenced objects or delegated controls may need additional RBAC before future creates or updates succeed. This includes manifests using custom ServiceAccounts, image pull Secrets, existing PVCs, Gateways, IngressClasses, StorageClasses, ServiceMonitor TLS references, backup/restore credential Secrets, workload identity metadata, custom executables, custom Hardened trust roots, or restore targets.

The admission checks run while the field is present, not only when the field changes. GitOps identities therefore need the relevant grants for unrelated future updates too.

usehelperimages remains accepted as a compatibility alias for custom executable authorization.

Verification

• make test-ci
• make docs-build
• go test ./hack/helmchart
• Focused envtest coverage for:
  • TestVAP_OpenBaoCluster_RequiresReferenceUseAuthorization
  • TestVAP_OpenBaoCluster_RequiresCloudIdentityAuthorization
  • TestVAP_OpenBaoRestore_RequiresReferenceAuthorization
  • OpenBaoRestore admission checks
  • kustomize policy/overlay contract checks

Reviewer Notes

The main review areas are the authorization boundary and onboarding impact:

• Confirm the mapping from CR fields to get, use, usecloudidentities, usecustomexecutables, useimagetrustroots, and restore matches the intended trust model.
• Confirm the stricter spec.serviceAccount.annotations handling is acceptable. Any ServiceAccount annotation now requires usecloudidentities; spec.podMetadata is limited to known identity selector keys instead of all metadata.
• Confirm docs make the new onboarding flow clear enough for tenant and GitOps users.

Checklist

• My code follows the project style guide.
• I have performed a self-review of my own code.
• I have added or updated tests, or explained why tests are not needed.
• I have updated documentation, or explained why docs are not needed.
• I have updated generated artifacts, or confirmed none are affected.
• I have checked that this change does not log or expose secrets, tokens, credentials, keys, or raw Secret data.
• I have run the relevant local checks, or documented why they were not run.
• Any dependent changes have been merged, published, or clearly called out.

[github-actions]

This PR is large (over 1000 lines). Consider breaking it down into smaller PRs.