Add operator lifecycle metadata columns to installed operators table

[perdasilva]

Analysis / Root cause:
Operators managed by OLM currently lack visibility into their lifecycle metadata — users cannot tell from the console whether an installed operator version is compatible with the current cluster version or what support phase it is in. This information is available from the lifecycle-server API but is not surfaced in the UI.

Solution description:
Add two new columns ("Cluster Compatibility" and "Support") to the Installed Operators table that display lifecycle metadata fetched from per-catalog lifecycle-server instances.

Backend changes (Go):

• New /api/olm/lifecycle/{catalogNamespace}/{catalogName}/{packageName} proxy endpoint in pkg/olm/lifecycle.go that forwards requests to the lifecycle-server for the given catalog.
• Service URL is derived from the catalog name (e.g., redhat-operators → redhat-operators-lifecycle-server.<namespace>.svc:8443).
• Requests are authenticated using the pod's service account bearer token via a new bearerTokenRoundTripper in pkg/olm/bearertoken.go.
• Input validation with strict regex patterns to prevent SSRF attacks.
• Reference RBAC manifests added to contrib/lifecycle-rbac.yaml.

Frontend changes (TypeScript/React):

• useOperatorLifecycle hook fetches lifecycle data with in-memory caching (5-minute TTL for success, 30-second TTL for errors) and request deduplication to avoid duplicate in-flight requests.
• ClusterCompatibilityStatus renders a green "Compatible" or red "Incompatible" PatternFly Label based on whether the operator version lists the current cluster's minor version in its openshiftCompatibility array. Shows "No data" when lifecycle info is unavailable.
• SupportPhaseStatus displays the last support phase end date with a green check icon (>12 months remaining) or yellow warning icon (≤12 months remaining). Tooltip shows the current phase name (e.g., "Maintenance support", "Extended life cycle support"). Shows "Self-support" when all phases have ended, or "No data" when lifecycle info is unavailable.
• Operator version matching uses minor version fallback (e.g., CSV version "2.16.0" matches lifecycle entry "2.16") to handle version format differences between CSVs and lifecycle metadata.
• Columns are visible by default in ClusterServiceVersionList when the feature is enabled.
• Feature is gated behind the OPERATOR_LIFECYCLE_METADATA flag, which is enabled only when TechPreview is active (window.SERVER_FLAGS.techPreview).

Screenshots / screen recording:

Test setup:

• Cluster with TechPreview enabled and lifecycle-server instances deployed for the relevant catalog sources.
• RBAC from contrib/lifecycle-rbac.yaml applied to the cluster.

Test cases:

• Verify "Cluster Compatibility" and "Support" columns appear in the Installed Operators table when TechPreview is enabled.
• Verify columns do NOT appear when TechPreview is disabled.
• Verify "Compatible" / "Incompatible" / "No data" labels render correctly based on lifecycle data.
• Verify support column shows last phase end date with green check (>12 months) or yellow warning (≤12 months).
• Verify tooltip on support column shows the current phase name.
• Verify "Self-support" displays when all support phases have ended.
• Verify "No data" label displays when lifecycle info is unavailable for both columns.
• Verify version matching works when lifecycle metadata uses minor versions (e.g., "2.16") and CSV uses full semver (e.g., "2.16.0").
• Verify backend returns 400 for invalid namespace/catalog name inputs.
• Verify backend returns 503 when lifecycle-server is unreachable.

Browser conformance:

• Chrome
• Firefox
• Safari (or Epiphany on Linux)

Additional info:

• The lifecycle-server is expected to be deployed per catalog source by the operator framework.
• Debug console.log statements are present for development — these should be removed before merging.
• The feature flag handler is registered via console-extensions.json and exposed as a new features module from the OLM package.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: perdasilva
Once this PR has been reviewed and has the lgtm label, please assign jhadvig for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment