fix: restore reserved suffix stripping in PrometheusNaming.sanitizeMetricName()

[zeitlinger]

Fixes #2087.

Supersedes #2094 with the same fix on a clean, signed-off commit so the DCO
check can pass.

sanitizeMetricName() was simplified in 1.6.0 to return its input unchanged
because any non-empty UTF-8 string is now a valid metric name. That silently
broke downstream tools — notably the JMX Exporter and the simpleclient bridge —
that call sanitizeMetricName() to normalize external names before passing them
to snapshot builders.

The missing stripping means a JMX attribute that produces
kafka_consumer_request_total as a raw name is no longer sanitized to
kafka_consumer_request. With inferCounterTypeFromName: true this triggers
unintended counter-type inference; with it false the metric is stored under the
wrong name, breaking exact-name registry lookups.

Changes

• Restore RESERVED_METRIC_NAME_SUFFIXES and the iterative suffix-stripping loop
  in PrometheusNaming.sanitizeMetricName().
• Keep the exact-match case, for example "_total" -> "total", in a dedicated
  pre-pass before the stripping loop.
• Update PrometheusNamingTest and MetricMetadataTest expectations.
• Add regression coverage for the JMX Exporter scenario and dot-variant corner
  case, for example .total.

// Before fix: suffix preserved -> metric stored as "kafka_consumer_request_total"
PrometheusNaming.sanitizeMetricName("kafka_consumer_request_total");

// After fix: suffix stripped -> metric stored as "kafka_consumer_request"
PrometheusNaming.sanitizeMetricName("kafka_consumer_request_total");

Counter.builder().name("events_total") is unaffected because the builder API
does not go through sanitizeMetricName().

Validation

• mise run build