Integrate kube-api-linter (KAL) for Kubernetes API type validation in feast-operator

The feast-operator defines custom Kubernetes API types (FeatureStore CRD) in infra/feast-operator/api/v1/ and infra/feast-operator/api/v1alpha1/, but currently does not lint these types against the Kubernetes API Conventions. The kube-api-linter (KAL) from kubernetes-sigs can catch common mistakes and enforce best practices for Kubernetes API types automatically.

The feast-operator already uses golangci-lint (configured in infra/feast-operator/.golangci.yml), but none of the enabled linters are specific to Kubernetes API conventions.

KAL checks for issues like:
- Required/optional field markers
- Status subresource conventions
- Condition and phase best practices
- Proper use of metav1.Condition types
- JSON tag and marker validation

Integrating KAL would catch API design issues early and reduce the manual review burden for API changes.

**Proposed Changes**

- Add kube-api-linter as a golangci-lint module or plugin in the feast-operator.
- Create a .custom-gcl.yml configuration to build a custom golangci-lint binary with KAL included.
- Update infra/feast-operator/.golangci.yml to enable and configure kubeapilinter, scoped to the api/ directory.
- Fix any existing violations surfaced by the linter.
- Integrate the linter into CI to prevent future regressions.

**References**
kube-api-linter repository: https://github.com/kubernetes-sigs/kube-api-linter