otel: agents reach their hive's collector by a swarm-wide name

Agents are handed `http://hive-collector.<swarm domain>:<port>` as their
otel endpoint instead of `http://<bridge IP>:<port>`. Every hive running
its collector contributes the name to `gateway.localNames`, so its own
dnsmasq answers it with its bridge IP, the way the queue's name already
works. The rendered meta flake then carries no hive-specific address,
which a swarm-level render needs (#4857, operator ruling 100744: "b").

hive-c0re's own exporter keeps the bridge address: on the host the name
may resolve to loopback through `gateway.localHostsEntry`, where the
receiver does not listen.

The name sits under the swarm domain and starts with `hive`, a fragment
no hive name may contain, so no hive's default domain can take it.

docs/scheduler/observability.md

@@ -42,8 +42,10 @@ destination in its own right. With both, telemetry goes to both. See
 **Telemetry leaves a hive exactly one way: through the collector that
 `enable` starts on the host.** Agents never talk to `endpoint` themselves —
 they export unauthenticated to a bridge address only their own containers can
-reach (`http://<bridgeIp>:<collector port>`; the otel module opens that port
-on the bridge itself). That collector forwards to the swarm's
+reach. They dial it as `http://hive-collector.<swarm domain>:<collector port>`,
+a name identical on every hive, which each hive's own dnsmasq
+answers with its bridge IP, so an agent's build carries no hive-specific
+address. The otel module opens that port on the bridge itself. That collector forwards to the swarm's
 ([`swarm/services.md`](../swarm/services.md#telemetry-collector-otel)), the
 single process holding the upstream credential and the only writer to the
 swarm's stores. No agent holds a copy, and neither does the hive.