Merge branch 'pratik/otel-phase10-workload-validation' into pratik/otel-sync-diagnostics

Brings phase-10 up to c531ac569b: the workload trigger now keys on changed paths
rather than branch name, and eleven span hierarchies gained assertions.

One conflict, in parent_child_relationships, and it was an append-both: each
branch added entries to the same array, so the resolution is the union of the
two. Nothing was chosen over anything. Both sides' final object was unclosed
because the conflict boundary cut mid-entry, with the shared closing brace after
the marker -- the first attempt asserted the wrong shape and failed loudly rather
than producing malformed JSON, which is why the assertion was there.

The two sets are disjoint by design and by ownership. phase-10 added the eleven
whose spans it owns: rpc.http_request -> rpc.process, three txq parentings and
seven under consensus.round and consensus.establish. This branch added the three
ledger-acquire phase parentings, which could not go on phase-10 because
ledger.acquire.header and ledger.acquire.txtree do not exist there.

Net effect on this branch: 21 relationships declared, 17 of them asserted, up
from 8 declared and 5 asserted. The four still skipped are the two wildcard
rpc.command.* families, which the validator cannot match because it resolves a
wildcard child to a single literal probe, and pathfind.compute, whose child never
fires under this workload.

Verification: no conflict markers repo-wide, no unmerged entries, two parents;
JSON parses; 21 relationships with no duplicates and every non-wildcard child
resolving to a declared span entry; counters still 48 span types and 74 unique
attributes; otel-naming exits 0; the workflow YAML parses and no longer carries a
branches key; pre-commit clean. Two C++ files in this worktree carry another
party's uncommitted work and were deliberately left alone -- only
expected_spans.json was staged, and both remain modified after the commit.

.github/workflows/telemetry-validation.yml

@@ -57,23 +57,53 @@ on:
         default: false
 
   push:
-    branches:
-      - "pratik/otel-phase*"
-      - "feature/otel-*"
-      - "feature/telemetry-*"
+    # No branches filter, deliberately. Branch names are not something this
+    # repository controls, so gating on one decides whether telemetry gets
+    # validated by what a branch is CALLED rather than by what it CHANGED. The
+    # previous list ("pratik/otel-phase*", "feature/otel-*",
+    # "feature/telemetry-*") silently excluded every other name, and because
+    # GitHub ANDs the branch and path filters the effect was total: pushes to
+    # pratik/otel-sync-diagnostics matched the paths below but not the branch
+    # glob, so this workflow was never dispatched there at all -- not queued,
+    # not skipped, no run to look at. Two rounds of harness fixes on that branch
+    # produced no signal before anyone noticed. The paths below already express
+    # the real question, which is whether a change can affect telemetry.
+    #
     # Keep these globs pointing at paths that actually exist. Two earlier
     # entries (include/xrpl/basics/Telemetry*.h, src/xrpld/app/misc/Telemetry*)
     # matched zero tracked files, so a pure C++ telemetry change never
     # triggered this workflow on push — only edits under docker/telemetry/**
-    # or to this file did. The telemetry sources live in the three telemetry
-    # module directories below.
+    # or to this file did.
     paths:
+      # This workflow, and the harness it runs.
       - ".github/workflows/telemetry-validation.yml"
       - "docker/telemetry/**"
+      # The telemetry modules themselves.
       - "include/xrpl/telemetry/**"
       - "src/libxrpl/telemetry/**"
-      - "src/libxrpl/beast/insight/**"
       - "src/xrpld/telemetry/**"
+      # beast::insight, whose gauges and counters this workflow asserts on.
+      # Both halves: the interface headers decide what the OTel collector can
+      # publish, so editing one moves the metric surface as surely as editing
+      # the implementation does.
+      - "include/xrpl/beast/insight/**"
+      - "src/libxrpl/beast/insight/**"
+      # The span-name and metric-name constants. These are the wire contract the
+      # harness asserts against by literal string, so a rename here compiles
+      # cleanly and silently empties the assertions. Matched by filename rather
+      # than directory because the convention colocates each header with the
+      # class it serves: they live under consensus/, overlay/, app/ledger/,
+      # app/main/, app/misc/, rpc/ and tx/, not under a telemetry/ directory.
+      - "**/*SpanNames.h"
+      - "**/*MetricNames.h"
+      # The GTests that pin those same constants.
+      - "src/tests/libxrpl/telemetry/**"
+      # The checkers that gate this surface. otel-naming derives the legal
+      # attribute and metric names from the headers above; the telemetry scripts
+      # enforce the histogram-bucket parity and regression-bound rules the
+      # harness depends on.
+      - ".github/scripts/otel-naming/**"
+      - ".github/scripts/telemetry/**"
 
 concurrency:
   group: telemetry-validation-${{ github.ref }}