Feat/crossplane provider keycloak

[tim-stasse]

Depends on #415

[gferreir]

Thanks for adding this! A few observations, mostly mirroring issues found in #415:

Bug — README paths reference operator/overlays/ which doesn't exist

The README uses operator/overlays/<channel> throughout (link, clone command, remote URL, and kustomization reference), but the actual overlay created in this PR lives at overlays/v1.5.0 — no operator/ subdirectory. Same pattern as #415, likely written anticipating the folder restructuring still under discussion there.

The <channel> placeholder approach is fine — the issue is only the operator/ prefix. Correct paths would be:

oc apply -k crossplane-provider-keycloak/overlays/v1.5.0
oc apply -k https://github.com/redhat-cop/gitops-catalog/crossplane-provider-keycloak/overlays/v1.5.0

Terminology — "channel" is an OLM/OperatorHub concept, not a Crossplane one

The README lists v1.5.0 as an available "channel" and asks users to "patch the channel". In the OLM ecosystem, a channel is a release stream you subscribe to (e.g. stable, alpha) and OLM handles upgrades automatically within it. Crossplane Providers work differently — they're installed via a direct OCI image reference with an explicit version tag. There's no subscription or channel concept.

Using "channel" here implies there may be stable or alpha options and creates false expectations for users familiar with either ecosystem. Replacing all occurrences of "channel" with "version" would be more accurate:

The current _overlays_ available are for the following versions:
- [v1.5.0](overlays/v1.5.0)

Missing prerequisite

The README doesn't mention that Crossplane must already be running in the cluster before applying this provider. Without it, oc apply will fail with no matches for kind "Provider" since the CRD won't exist. A short prerequisites section linking to crossplane-system (from #415) would help:

## Prerequisites
Crossplane must be installed before applying this provider.
See [crossplane-system](../crossplane-system) for installation.

Minor: base/provider.yaml includes namespace: crossplane-system on the Provider resource, which is cluster-scoped — Kubernetes will silently ignore the field, but it's misleading for users who try oc get provider -n crossplane-system.

The version pinning in patch-provider.yaml (v1.5.0) and the base/overlay pattern look correct. Resolving the operator/ discussion in #415 will clarify the right path structure for this PR as well.