Expected Behavior

The Service the Operator creates for the offline (Arrow Flight / gRPC) server should set the native Kubernetes appProtocol: grpc on its port, so Istio (or any protocol-aware mesh) negotiates HTTP/2 instead of guessing from the port name — the same fix #6367 already applied to the registry Service.

Current Behavior

getServiceAppProtocol() only special-cases the registry service:

func (feast *FeastServices) getServiceAppProtocol(feastType FeastServiceType, isRestService bool) *string {
	if feastType == RegistryFeastType && !isRestService && feast.isRegistryGrpcEnabled() {
		return ptr.To("grpc")
	}
	return nil   // offline falls through here despite also speaking gRPC
}

The offline Service still gets name: http, no appProtocol — Istio negotiates HTTP/1.1 for gRPC (Arrow Flight) traffic to it.

Steps to reproduce

• Deploy a FeatureStore with an offline server, in a cluster with Istio sidecar injection enabled for the Feast namespace.
• Inspect the generated offline Service: its port is named "http" (no appProtocol set).
• Send gRPC traffic to that Service through the mesh and observe protocol negotiation issues consistent with HTTP/1.1 (e.g. via istioctl proxy-config).

Specifications

• Version: 0.66.0 / current infra/feast-operator on master
• Platform: Kubernetes with Istio sidecar mesh
• Subsystem: infra/feast-operator Service rendering

Possible Solution

if (feastType == RegistryFeastType && !isRestService && feast.isRegistryGrpcEnabled()) ||
    feastType == OfflineFeastType {
	return ptr.To("grpc")
}

Same helper, same pattern #6367 already established — just extend the condition to OfflineFeastType.