atecontroller metrics are never scraped

[Jefftree]

atecontroller is the only control plane component with no Prometheus target. It uses
InitMetricsPushOnly (cmd/atecontroller/main.go:112) and its pod carries no prometheus.io
annotations, so the manager's :8080 is never scraped, while ateapi, atelet and atenet-router
serve /metrics on 9090 and are. docs/observability.md:178 assumes every component is scraped.

Should atecontroller move to the InitMetrics plus StartMetricsServer shape on 9090, or is
push-only intended, in which case the dead :8080 port should go instead?

[YQ-Wang]

Hi, I’d be happy to work on this if no one else has already started. I checked the metrics wiring introduced in #754, and the push-only path appears intentional: atecontroller bridges controller-runtime’s registry into its OTLP reader, and the metrics e2e verifies that controller_runtime_* reaches the collector. A direct switch to InitMetrics plus StartMetricsServer would split the registries and could regress that OTLP path.

My proposed scope is therefore to disable controller-runtime’s unused :8080 metrics listener, remove the corresponding metrics-only Service/container port, and update docs/observability.md so it distinguishes direct Prometheus scrape targets from atecontroller’s OTLP path. I would keep the existing bridge/e2e coverage and add focused coverage for the disabled manager endpoint. Please let me know if this direction sounds reasonable.