Document and standardise HTTP health endpoint paths across all DFE binaries

[kazmosahebi]

Issue

The rustlib HTTP server serves /readyz, /healthz, and /metrics, but
downstream consumers (dfe-docker compose, K8s manifests) often probe
/health/ready -- which may or may not exist depending on each binary's
HTTP wiring.

In dfe-docker, the compose healthchecks for dfe-receiver, dfe-fetcher,
dfe-archiver, dfe-loader, dfe-transform-vector, dfe-transform-vrl
all use /health/ready. None of those are guaranteed by rustlib; they
happen to work or not work per binary depending on what extra routes
that binary installed on top of the rustlib defaults.

This is partly a documentation gap (the canonical endpoint paths are not
prominently documented) and partly a consistency gap (some binaries may
expose legacy /health/ready aliases, others may not).

Proposed solution

• Document the canonical rustlib HTTP endpoints in the rustlib README
  and STATE.md:
  • /healthz -- liveness
  • /readyz -- readiness
  • /startupz -- startup (if implemented)
  • /metrics -- Prometheus scrape
• Confirm every DFE binary built on rustlib exposes the same set with
  no aliases. Add a CI check (smoke test against the built image)
  that hits each endpoint and asserts 200/503 as expected.
• Either drop any legacy /health/ready route, or document it as a
  permanent alias of /readyz and add a corresponding smoke test.
• Once the rustlib side is settled, dfe-docker compose can switch
  every healthcheck to /readyz in one PR.

Additional info

This blocks a clean healthcheck rewrite in dfe-docker. The compose
files currently all point at /health/ready and nobody has audited
whether each binary actually serves it. Need the canonical answer
from rustlib before doing the dfe-docker fix.

Observed: rustlib 2.7.1 + DFE 2.2 components.