bug: restore OM1/protobuf suffix compatibility after #1955

[zeitlinger]

Summary

feat: move suffix handling to scrape time (#1955) introduced a user-visible
compatibility regression for non-OpenMetrics exposition.

For gauge names that merely end in suffix-like dotted strings such as
.created or .total, OM1 and protobuf output changed from the legacy stripped
name to the literal suffixed name.

This surfaced while wiring downstream Micrometer compatibility in
#2093.

Regression

Examples:

Input	Previous OM1/protobuf output	Regressed output	Format
Gauge("test3.created")	test3	test3_created	OM1, protobuf
Gauge("test6.total")	test6	test6_total	OM1, protobuf

OpenMetrics can reasonably keep the newer literal behavior, but the OM1 and
protobuf change breaks downstream expectations and is not just an internal-only
representation change.

Why this is a bug

This was initially easy to interpret as a docs/migration issue, but the
Micrometer downstream test failure turned out to be exercising a real behavior
change in what users see from OM1/protobuf scrapes.

That is distinct from the separate Micrometer adapter bug also found during the
same work:

• Micrometer needed to expose snapshot-derived MultiCollector metadata for
  registration-time collision detection.

But for the suffix case, the prom-side issue is specifically that non-OM2
output changed incompatibly for dotted gauge names.

Expected behavior

For OM1 and protobuf compatibility:

• Gauge("test3.created") should expose as test3
• Gauge("test6.total") should expose as test6

OpenMetrics may continue to expose the literal encoded names.

Status

Addressed in:

• PR: fix: restore OM1/protobuf micrometer suffix compatibility #2093

That PR restores the legacy OM1/protobuf behavior while keeping OpenMetrics on
literal-name handling. The added Micrometer job in that PR is regression
coverage for the bug, not the bug fix itself.