fix(telemetry): root peer.validation.receive and peer.proposal.receive spans

These inbound peer-message entry points (kConsumer) used span(), which
inherits whatever span is active on the peer thread — including a leaked
tx.receive scope — so validations/proposals were wrongly nested under
unrelated transaction traces. rootSpan() starts a fresh trace root.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

OpenTelemetryPlan/09-data-collection-reference.md

@@ -211,6 +211,11 @@ Controlled by `trace_peer` in `[telemetry]` config. **Enabled by default** (high
 | `peer.proposal.receive`   | —      | PeerImp.cpp | Consensus proposal received from peer |
 | `peer.validation.receive` | —      | PeerImp.cpp | Validation message received from peer |
 
+A `—` parent means the span is a fresh trace root (`kConsumer`): it is started
+via `SpanGuard::rootSpan()` at the inbound-message entry point and never
+inherits an ambient span left active on the peer thread, so it does not nest
+under an unrelated transaction's trace.
+
 **Where to find**: Tempo → TraceQL: `{resource.service.name="xrpld" && name=~"peer.*"}`
 
 **Grafana dashboard**: _Peer Network_ (`peer-network`)