[FEATURE] Publish an official Kubernetes version compatibility matrix

[younsl]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct

📝 Feature Summary

Provide an official, documented Kubernetes version compatibility matrix that maps each kagent release to the Kubernetes minor versions it is tested and supported against.

❓ Problem Statement / Motivation

Today there is no published statement of which Kubernetes versions a given kagent release supports. This creates real friction for operators:

• Upgrade path is unclear. When planning a cluster upgrade or a kagent upgrade, users cannot tell whether their target Kubernetes version is supported without reading source, CRD manifests, or CI config.
• No signal on breaking changes. There is no documented boundary telling users when a kagent version drops or adds support for a Kubernetes minor version.
• Production risk. Platform teams (running kagent alongside other controllers) need a stated support window to make safe rollout decisions and satisfy internal change-management.

Mature Kubernetes ecosystem projects treat this as a first-class part of their release docs. Users already expect it. For example, KEDA publishes a Kubernetes Compatibility matrix with an explicit N-2 testing policy, and Kyverno documents supported Kubernetes versions per release. cert-manager and Istio do the same.

💡 Proposed Solution

Add an official compatibility matrix to the kagent documentation and release process:

1. A version matrix table mapping each kagent release (e.g. current + last 2-3) to its tested/supported Kubernetes minor version range.
2. A stated support policy (e.g. an N-2 window like KEDA's) so users can predict future support without waiting for each release.
3. A caveat line matching the Kyverno convention: untested versions may work but carry no guarantee.
4. Sourced from CI. Ideally the tested versions are derived from the actual e2e/integration test matrix so the doc cannot drift from reality.

Suggested placement: a section in the install/operate docs, and/or the release notes for each tagged release.

🔄 Alternatives Considered

• Read CI config / kind versions manually — works but is undiscoverable, undocumented, and offers no support guarantee.
• Infer from CRD apiVersion and Go client-go version — indirect, error-prone, not a substitute for a stated policy.

🎯 Affected Service(s)

Multiple services / System-wide

📚 Additional Context

Reference implementations from comparable CNCF / Kubernetes-ecosystem projects:

• KEDA — Kubernetes Compatibility matrix
• Kyverno — Releases & supported Kubernetes versions
• cert-manager — Supported releases
• Istio — Support status of releases

🙋 Are you willing to contribute?

• I am willing to submit a PR for this feature