fix(operator): set appProtocol: grpc on registry gRPC Service

[tmvfb]

Summary

The registry Service (the use case is local registry + server.grpc enabled, i.e. SQLite) is always created with name: http and no appProtocol. This causes service meshes (notably Istio) to misclassify the registry gRPC traffic as HTTP/1.1, breaking connections in two places simultaneously:

• Client-side envoy: sees name: http → downgrades to HTTP/1.1. gRPC requires HTTP/2.
• Server-side envoy: builds its inbound listener for the registry port as HTTP/1.1 → receives gRPC (HTTP/2) frames → sends RST with "protocol error".

Both failures stem from the same missing field. The fix is minimal: set appProtocol: grpc on the registry gRPC Service port.

Changes

• Added getServiceAppProtocol helper that returns ptr.To("grpc") for the registry gRPC Service and nil for all other services.
• Set AppProtocol on the ServicePort in setService via this helper.
• Added k8s.io/utils/ptr import to services.go (already a transitive dependency, used in tests).

Effect

With appProtocol: grpc set, Istio and other service meshes correctly identify the port as gRPC and handle HTTP/2 and mTLS normally, no workarounds required.

Testing

go vet ./internal/... passes. Existing operator unit tests are unaffected (they assert on port number and name, not appProtocol). Manual verification on a cluster with Istio sidecar injection confirmed gRPC connectivity works end-to-end after this change with no additional mesh configuration.

Workaround

• Client-side envoy downgrades to HTTP/1.1. Fixed by creating an alt-Service with appProtocol: grpc.
• Server-side envoy builds its inbound listener for port 6570 as HTTP/1.1 and rejects incoming HTTP/2 with a protocol error. The only workaround is traffic.sidecar.istio.io/excludeInboundPorts: "6570" on the feast-server pod to bypass it entirely.
• With the server-side envoy bypassed there is nothing to terminate mTLS, so a DestinationRule with tls: DISABLE is also required to stop the client from attempting it.