The ate-otel-config ConfigMap named the collector of the GKE managed OTel
addon on each cluster that is not kind. A cluster without that addon has no
gke-managed-otel namespace, thus each component failed to find the collector
one time each minute, and the telemetry stopped with no message. It reads as a
fault of the network, and not as an absent dependency. Substrate must also run
on a cluster that has no collector, and it must not assume one vendor.

ate-setup now takes --observability none|otlp|gke|kind. With no flag, a first
install tests the cluster for the collector of the managed addon and takes mode
gke when it is there, and mode none when it is not. Mode none exports nothing;
each component still serves its own /metrics endpoint. Mode otlp uses the address of --otlp-endpoint, mode gke the collector
of the addon, and mode kind the in-cluster collector that a kind install
applies, which is also its default. One file under manifests/ate-install/otel/
supplies the ate-otel-config ConfigMap for each mode, and a preflight stops the
install with a message when the collector of the mode is absent.

The mode is state of the cluster: the install writes it as the
ate.dev/observability-mode annotation and reads it back, thus a deploy of one
component keeps the collector that the cluster has. No kustomize bundle carries
a copy of the ConfigMap, thus the installer is the one writer and no later
apply replaces the selected mode.

internal/serverboot builds no OTLP exporter when the endpoint is empty, when
OTEL_SDK_DISABLED is true, or when the standard exporter variables say none.
The tracer provider stays registered, thus the spans keep their IDs and the
logs keep the trace_id that joins them.

hack/install-ate.sh keeps its two cases, the kind collector for a kind install
and the GKE managed one for each other install. It follows the files to their
new place and gets no mode flag, because ate-setup replaces it.

Two workloads kept the collector of the install before them, with no
message, when the mode changed.

An atelet DaemonSet carries the version suffix of the install that made
it (atelet-${SUBSTRATE_VERSION_SUFFIX}), thus the restart of a DaemonSet
named atelet reached nothing at all, and reported nothing: an absent
DaemonSet is not an error, because a deploy of one component has only
that component. The restart now goes by the app=atelet label, which also
covers the second DaemonSet that a cluster in a rolling upgrade holds.

atenet-egress reads the ConfigMap with envFrom, as its own manifest says,
and it was absent from the list of Deployments. Both egress manifests
declare one Deployment of that name, thus one entry covers the shipped
gateway and the sdsmint one.

A test now holds the list to the manifests: it scans them for each
workload that takes the ConfigMap through envFrom, and fails when one of
them has no restart. A second test stamps the workloads of a cluster in a
rolling upgrade and reads the annotation back.