fix(observability): reserve a loopback OTLP relay address

[afourniernv]

Summary

Use an OpenShell-reserved loopback address for sandbox OTLP export so current NeMo Relay can send traces, logs, and metrics through the mediated telemetry path without a workload-side bridge.

This is the third signal-compatibility layer in the fork-only draft stack. OpenShell still intercepts the connection before the workload network stack can deliver it locally.

Related Issue

Extends NVIDIA#2641 and NVIDIA#3196. This draft does not close either issue.

Changes

• move the reserved OTLP/HTTP endpoint from 192.0.0.8:4318 to 127.0.0.8:4318
• reserve that exact destination in the seccomp broker while preserving ordinary loopback behavior
• add Linux broker coverage proving the connection is staged for the supervisor
• update the supervisor and user documentation

Testing

• cargo test -q -p openshell-core relay_address_is_a_reserved_loopback_label
• cargo test -q -p openshell-server otel_relay
• cargo test -q -p openshell-supervisor-process otlp
• mise run pre-commit
• Hermes 0.21.5 with NeMo Relay 0.9.3 exported a 16-span tool turn, logs, and metrics through the OpenShell gateway to Phoenix without a forwarding shim
• spoofed openshell.sandbox.id and openshell.telemetry.source values were replaced on traces, logs, and metrics
• a workload listener bound to 127.0.0.8:4318 accepted zero connections while Relay telemetry still reached the collector

Checklist

• Changes are scoped to current-Relay endpoint compatibility
• Ordinary loopback connections retain their existing behavior
• Tests and documentation are updated
• Commit is signed off for DCO

Stack

Draft stacked on #7 (codex/3196-stack-otlp-metrics). Review this PR as the reserved-loopback-only delta from that branch.