Standardize health endpoint path and response across services

[priyaselvaganesan]

Description

Services in this repository use inconsistent paths and response formats for their health endpoints.

Service	Plane	Path	Response
grpc-proxy	Invocation	/health	JSON with dependency status (NVCF API gRPC, NATS) via hellofresh/health-go
vanity-gateway	Invocation	/health	JSON with dependency status (NVCF API HTTP) via hellofresh/health-go
ratelimiter	Invocation	/health	200 or 500 based on Olric cluster health
http-invocation	Invocation	/health	unknown
llm-api-gateway	Invocation	/healthz	200 empty body (unconditional)
helm-reval	Control	/healthz	200 OK body "OK" (plain text, unconditional)
nats-auth-callout	Control	/healthz + /health	JSON {"status":"ok"} (unconditional)
function-autoscaler	Control	/health, /admin/health/liveness, /admin/health/readiness	JSON with component health status
nvcf-unbound	Compute	/health	200 OK body "ok" (plain text, unconditional)
nvca	Compute	/healthz	200 via go-lib core framework
nvsnap	Compute	/health (main + agent), /healthz (webhook), /v1/healthz (blobstore)	varies across three internal servers
worker-task	Compute	/v1/health/live + /v1/health/ready	via go-lib nvkit
worker-utils	Compute	/v1/health/live + /v1/health/ready	JSON via hellofresh/health-go

Note: byoo-otel-collector, ess-agent, image-credential-helper, worker-init, and worker-llm-credentials have no self-health HTTP endpoint found in this repo.

Definition of Done

• All services use a single consistent health endpoint path
• The path is registered as the standard in go-lib
• Helm chart liveness and readiness probe configurations reflect the chosen path
• Response format consistency across services needs further triaging — some services perform real dependency checks while others return unconditional 200 OK, which may be intentional or may represent gaps in health signal coverage