docs(telemetry): use snake_case tuning/resource namespaces in getobject bucket notes

develop renamed CamelCase namespaces to snake_case (#7933): Tuning:: ->
tuning:: and Resource:: -> resource::.

OpenTelemetryPlan/09-data-collection-reference.md

@@ -1361,7 +1361,7 @@ macros, not as `MetricsRegistry` members: the two rejection counters in
 **Per request, not per object.** `getobject_lookup_us` times the whole fetch
 loop once, and `getobject_lookups_total` adds the batch hit and miss totals in
 two calls. Incrementing per object on a loop bounded by
-`Tuning::kHardMaxReplyNodes` (12288) would cost measurably and add no
+`tuning::kHardMaxReplyNodes` (12288) would cost measurably and add no
 information the batch totals do not already carry.
 
 **All three histograms need an explicit bucket view.** The SDK's default
@@ -1387,7 +1387,7 @@ observation in one or two buckets and make the distribution unreadable.
 `addHistogramView()` exists to take caller-supplied boundaries for exactly this
 case.
 
-- **Counts** run 1 to `Tuning::kHardMaxReplyNodes` (12288). The low end is
+- **Counts** run 1 to `tuning::kHardMaxReplyNodes` (12288). The low end is
   fine-grained because the honest sync path asks for at most 8 objects, so the
   interesting distinction is between a normal request and a large one. The upper
   bounds follow the charge size bands — `kBandSmallMax` (64) and
@@ -1395,7 +1395,7 @@ case.
   with each price change.
 - **Charges** run 0 to roughly 99k for a full-size all-miss request. Two of the
   boundaries are the resource thresholds that decide a peer's fate:
-  `Resource::kWarningThreshold` (5000) and `Resource::kDropThreshold` (25000),
+  `resource::kWarningThreshold` (5000) and `resource::kDropThreshold` (25000),
   both in `include/xrpl/resource/detail/Tuning.h`. Placing bucket edges exactly
   there lets a panel read off how close real charges run to a warning or a drop,
   rather than interpolating across an edge.