fix(security): enforce hardened contract for unsafe controls

[dc-tec]

Summary

Enforces the Hardened profile as a reject-by-default security contract for unsafe escape hatches.

This adds a shared Hardened contract validator and applies it consistently across admission, controller status, backup, restore, and upgrade snapshot paths. Hardened specs now reject or mark unsafe use of TLS disablement, insecure TLS verification, wildcard/ambient egress, raw ingress widening, dangerous runtime flags, CR-controlled image trust roots, and ambient backup/restore credentials.

Existing unsafe Hardened specs are not adopted into privileged behavior silently: controller status marks them as SecurityRisk=True and ProductionReady=False, while lifecycle paths reject privileged side effects where possible.

Related Issues

None.

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 tightens behavior for spec.profile: Hardened.

New or updated Hardened specs are rejected when they use unsafe escape hatches, including disabled TLS, skip-verify settings, wildcard or non-explicit network egress, raw ingress widening, unsafe runtime flags, CR-controlled custom CA/image trust roots, or ambient backup/restore credentials.

Existing unsafe Hardened specs are not deleted, but they are marked not production-ready and may have backup, restore, or upgrade snapshot operations rejected until the spec is made explicit and compliant.

For backup and restore identity, Hardened now requires an explicit credentials secret, workload identity, or S3-only roleArn. Non-S3 providers must not rely on roleArn as a stand-in for explicit identity.

This should be called out in the release line because Hardened users may need to update specs before future reconciles or lifecycle operations succeed.

Verification

• GOFLAGS=-mod=vendor go test ./internal/platform/hardenedcontract -count=1
• GOFLAGS=-mod=vendor go test ./internal/service/workloadidentity -count=1
• GOFLAGS=-mod=vendor go test ./internal/service/backup -count=1
• GOFLAGS=-mod=vendor go test ./internal/service/restore -count=1
• GOFLAGS=-mod=vendor go test ./internal/service/upgrade/snapshot -count=1
• Targeted integration tests for Hardened admission and kustomize policy contracts
• Hardened E2E suite passed locally: 7 passed, 0 failed
• make verify-generated
• make verify-helm
• make docs-build
• make lint-ci via pre-push hook

Reviewer Notes

The main review focus is whether the Hardened contract boundaries are correct and consistently applied between Go validation, admission policies, status reporting, and lifecycle operations.

The intended model is that Hardened remains usable for production OpenBao deployments, but any escape hatch must either be removed from the Hardened spec or represented through an explicit, auditable configuration path.

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.