fix(telemetry): assert the rpc.command hierarchies, whose skips described dead code

Both rpc.command.* relationships were skipped on the claim that
_validate_parent_child collapses a wildcard child to one literal name via
child_name.replace("*", "server_info"). That code does not exist. d059f21bf3
removed it on 2026-08-14 and replaced it with _span_name_matches(), which globs
through fnmatch.fnmatchcase; the check's own comment now reads "globs for
wildcard contracts". So any rpc.command.<anything> under the parent satisfies the
contract, and the command mix the sampled traces happen to carry no longer
matters -- which was the entire basis of the skip. The wildcard_probes map that
does still substitute a literal name belongs to the span-EXISTENCE check
(validate_telemetry.py:545, :554), not to the hierarchy check.

The WebSocket entry's reason went stale the day that code was deleted. The
rpc.process entry's is worse and is mine: c531ac569b rewrote that reason to fix a
different error in it -- it had claimed rpc.process cannot appear under a
WebSocket-only harness, when it appears on every run because
run-full-validation.sh polls each node over HTTP with curl -- and while fixing
that I copied the wildcard claim across from the stale WS entry without checking
it. Correcting one false statement in a note is not a licence to inherit the
next one.

Both are now asserted. Both parents emit on a normal run: rpc.ws_message is the
WebSocket root the load generator drives, and rpc.process reports 5 traces from
the curl readiness and validated-ledger polls, every one of which runs a command.

This also retires the plan's Task 5 without writing any validator code. The task
was scoped as "teach the validator to match a wildcard child"; it already does,
and had for two weeks. Checking the code before writing the feature turned a code
change into a data change.

Verification: JSON parses; 18 relationships, 15 asserted and 3 skipped, up from
13 asserted; the three remaining skips are txq.accept_tx (newest-N sampling of a
conditional child), rpc.ws_message -> rpc.process (genuinely not a code
relationship) and pathfind.compute (child never fires); counters still 41 span
types; churn 2/6; otel-naming exits 0; pre-commit clean. Whether these two hold in
a real trace is what the next run decides -- both ends emitting is necessary, not
sufficient.

docker/telemetry/workload/expected_spans.json

@@ -394,16 +394,12 @@
     {
       "parent": "rpc.ws_message",
       "child": "rpc.command.*",
-      "description": "WebSocket message contains the per-command span — the real relationship on the harness WS path (rpc::doCommand at RPCHandler.cpp:271 creates an ambient child of the rpc.ws_message scope inside the same coroutine)",
-      "skip": true,
-      "skip_reason": "Code-verified real, but not assertable by the current validator. _validate_parent_child() collapses the wildcard to the single literal name via child_name.replace(\"*\", \"server_info\") and samples only the 3 most recent parent traces. Each rpc.ws_message trace carries exactly one command, and server_info is 25/100 of rpc_load_generator.py's DEFAULT_WEIGHTS, so roughly 42% of healthy runs would sample three non-server_info traces and fail. Asserting this needs the validator to accept a wildcard child as a prefix match (or to raise the trace sample size); until then the relationship is documented, not enforced."
+      "description": "WebSocket message contains the per-command span — the real relationship on the harness WS path (rpc::doCommand at RPCHandler.cpp:271 creates an ambient child of the rpc.ws_message scope inside the same coroutine). Un-skipped 2026-08-26. The skip existed because _validate_parent_child() used to collapse the wildcard to one literal name via child_name.replace(\"*\", \"server_info\"), which made the check depend on which command the sampled traces happened to carry -- server_info is 25/100 of rpc_load_generator.py's DEFAULT_WEIGHTS, so a healthy run could sample three non-server_info traces and fail. That code no longer exists: d059f21bf3 replaced it with _span_name_matches(), which globs via fnmatch.fnmatchcase, and the check's own comment now reads \"globs for wildcard contracts\". Any rpc.command.<anything> under the parent therefore satisfies the contract and the command mix no longer matters. The reason had simply gone stale for two weeks."
     },
     {
       "parent": "rpc.process",
       "child": "rpc.command.*",
-      "description": "Processing span contains per-command span (HTTP/JSON-RPC path only)",
-      "skip": true,
-      "skip_reason": "Real relationship, skipped for a VALIDATOR limitation, not for absence: _validate_parent_child() resolves the wildcard child to one literal probe name, so it cannot assert a family whose members vary per request. Corrected 2026-08-26 -- the earlier reason claimed there are no rpc.process traces to check because that span exists only on the HTTP/JSON-RPC path while the load generator is WebSocket-only. The premise is right and the conclusion is wrong: rpc.process DOES appear, 5 traces on a normal run, because run-full-validation.sh polls each node's HTTP port with curl for readiness and validated-ledger progress (:449, :502). Those curl calls are what produce rpc.http_request and its rpc.process child, entirely independently of the load generator. Anyone acting on the old reason would have gone looking for a way to make the harness speak HTTP, which it already does. That same reason also said the WS-path equivalent is 'asserted above instead'; it is not, rpc.ws_message -> rpc.command.* is skipped for this identical wildcard limitation. To assert either, teach _validate_parent_child to accept a wildcard child by matching any span whose name has the declared prefix."
+      "description": "Processing span contains the per-command span, on the HTTP/JSON-RPC path. Un-skipped 2026-08-26 for the same reason as the WebSocket pair above: the validator globs a wildcard child via _span_name_matches() and has done since d059f21bf3, so the 'resolves the wildcard to one literal probe' claim this entry carried was describing code deleted two weeks earlier. That claim was not inherited here by accident -- it was copied from the stale WS entry while correcting a DIFFERENT error in this same reason, without checking it. Both ends emit: rpc.process reports 5 traces on a normal run, not from the WebSocket-only load generator but because run-full-validation.sh polls each node's HTTP port with curl for readiness and validated-ledger progress (:449, :502), and every such request runs a command."
     },
     {
       "parent": "ledger.build",