fix(otel): let the SDK resolve hive-c0re's OTLP endpoint

hive-c0re's container-resource exporter has POSTed to a 404 for as long as
it has existed, silently: it passed the collector's base address to
`with_endpoint`, which the SDK takes verbatim, so every export went to `/`
instead of `/v1/metrics`. Nothing reported it — OTLP export failures go to
an error handler no binary here installs — so the daemon logged "exporter
enabled" and delivered nothing. VictoriaMetrics has never held a sample
under `service.name=hyperhive-c0re`.

Fix the way the rest of the repo already resolves an endpoint: an endpoint
option names a BASE, and the layer that knows the signal appends to it.
`hive-metric` — same SDK, same collector — never calls `with_endpoint`, and
`docs/observability.md` documents the append as system behaviour; the one
place a full path is spelled out is the VictoriaMetrics exporter, because
its far end is not a standard OTLP path.

So drop the call. The builder is now byte-identical to hive-metric's, and
hive-c0re's unit carries the standard `OTEL_EXPORTER_OTLP_ENDPOINT` for the
SDK to read. The address is bound once in nix and consumed twice, so what a
hive hands its agents and what it exports to itself cannot drift.

The enable signal moves to that same standard variable: "configured" and
"where it actually goes" become one string rather than two that agree by
convention. `HYPERHIVE_OTEL_*` keeps its own job, the agent-config
transport meta.rs reads — a name the SDK has never known, which is the bug.

The test changes shape with the fix. The old one asserted a URL this module
built; the new one pins that the exporter is gated on the variable the SDK
itself reads, because the fix is now an absence and an absence is what a
later "the endpoint is right there, just pass it" edit puts back.

Refs #3402

nix/host-modules/hive-c0re/environment.nix

@@ -81,6 +81,11 @@ in
   # don't render no-op env lines.
   let
     otel = config.services.hyperhive.otel;
+    # The first hop, bound once and consumed twice below: what agents are
+    # handed, and where hive-c0re's own exporter sends. One binding so the
+    # address a hive tells its agents about and the one it uses itself
+    # cannot drift apart.
+    firstHop = "http://${config.services.hyperhive.network.bridgeIp}:${toString otel.collector.port}";
   in
   {
     # `otel.endpoint` means "where telemetry ultimately goes" and keeps
@@ -88,7 +93,20 @@ in
     # always this hive's own collector. Deriving it rather than
     # redefining `endpoint` is what lets every existing deployment keep
     # its configured value untouched.
-    HYPERHIVE_OTEL_ENDPOINT = "http://${config.services.hyperhive.network.bridgeIp}:${toString otel.collector.port}";
+    HYPERHIVE_OTEL_ENDPOINT = firstHop;
+    # hive-c0re's OWN container-resource exporter (stats/otel_metrics.rs)
+    # reads the STANDARD OTLP variable — the same one hive-metric and every
+    # agent read — and lets the SDK resolve the URL, which appends the
+    # signal path (`/v1/metrics`). Handing the SDK an address
+    # programmatically instead takes it verbatim: it POSTs to the
+    # collector's root, gets a 404 on every export, and says nothing,
+    # because OTLP export failures go to an error handler no binary here
+    # installs — the daemon logged "exporter enabled" and never delivered a
+    # sample, for as long as it had that exporter. The variable above cannot
+    # replace this one:
+    # it is the agent-config transport meta.rs reads, and the SDK does not
+    # know that name.
+    OTEL_EXPORTER_OTLP_ENDPOINT = firstHop;
     # The first hop is the collector's OTLP/HTTP receiver, which speaks
     # protobuf regardless of what the upstream wants — `otel.protocol`
     # describes the *upstream* link, and the collector's own exporter is