test(telemetry): assert the tx-tree acquire hierarchy again

The sampling fix that just merged forward removes the only reason this was
skipped. The check no longer inspects the three newest parent traces; it asks
Tempo for traces containing both parent and child.

Worth recording why this phase was the one that failed while its two siblings
passed, because the original assertion treated all three as equivalent and they
are not. InboundLedger.cpp opens each phase only when that piece is still needed:
header on !haveHeader_ (:672), astree in the else of haveState_ (:689), txtree in
the else of haveTransactions_ (:698). A node acquiring a ledger here almost always
lacks the account-state tree, so astree opens on essentially every acquire. But it
usually already holds the transaction set -- every node sees the same relayed
transactions and builds the same set -- so txtree opens on a minority of acquires.
The child was always emitting, 5 traces of its own on the run that failed; it just
was not in the three most recent acquires.

That is now all three sampling-caused skips retired: txq.accept -> txq.accept_tx
and this one asserted, and txq.enqueue -> txq.batch_clear narrowed to its real
remaining cause, a child that never fires under this workload at all.

Contract on this branch: 24 relationships, 19 asserted, 5 skipped, and zero spans
declaring a parent without an entry. The five are the two pathfind pairs and the
pathfind.request parent (pathfinding disabled and no path-finding RPC issued),
rpc.ws_message -> rpc.process (not a code relationship -- rpc.process is a child
of rpc.http_request), and txq.batch_clear. None is a sampling artifact.

Verification: JSON parses; the four validator tests pass after the merge; 0
unaccounted parentings; counters still 48 span types and 74 unique attributes;
otel-naming exits 0. Whether this holds against a live Tempo is what the run this
push triggers decides -- the stub proves the query shape, not the corpus.

docker/telemetry/workload/expected_spans.json

@@ -532,9 +532,7 @@
     {
       "parent": "ledger.acquire",
       "child": "ledger.acquire.txtree",
-      "description": "Ledger acquire contains the transaction-tree fetch phase.",
-      "skip": true,
-      "skip_reason": "Asserted on 2026-08-26 alongside the header and astree phases and it FAILED on run 33002568549 -- \"ledger.acquire.txtree not found in ledger.acquire traces\", the single failure in 279 checks. Skipped rather than left red. Not a missing span: it reports 5 traces of its own on that same run, one per node. The three phases are NOT equally conditional, which is what the original entry got wrong by treating them as identical. InboundLedger.cpp opens each only when that piece is still needed -- header on !haveHeader_ (:672), astree in the else of haveState_ (:689), txtree in the else of haveTransactions_ (:698). A node acquiring a ledger in this cluster almost always lacks the account-state tree, so astree opens on essentially every acquire and its assertion holds; but it usually ALREADY HOLDS the transaction set, because every node sees the same relayed transactions and builds the same set, so haveTransactions_ is true and no txtree phase opens. It fires only on the minority of acquires where the set was genuinely missing. Combined with _validate_parent_child sampling the 3 newest parent traces (validate_telemetry.py:803), the sampled acquires carry header and astree but no txtree. Same shape as the txq.accept -> txq.accept_tx skip, and the same fix applies to both: prefer parent traces that CONTAIN the child over newest-N. That one change would retire this skip, txq.accept_tx and txq.batch_clear together, which is now the highest-value improvement left in this harness."
+      "description": "Ledger acquire contains the transaction-tree fetch phase. Un-skipped once the hierarchy check stopped sampling only the newest parent traces. This phase is the conditional one of the three: header opens on !haveHeader_ (InboundLedger.cpp:672) and astree in the else of haveState_ (:689), both of which hold on essentially every acquire, while txtree opens only in the else of haveTransactions_ (:698) -- and a node in this cluster usually already holds the transaction set, because every node sees the same relayed transactions and builds the same set. So the phase fires on a minority of acquires, which is precisely the case newest-N sampling of the parent got wrong; the child was always emitting, just not in the three most recent acquires."
     },
     {
       "parent": "rpc.command.*",